Ohjelmistokehitysprosessi. Ohjelmistosuunnittelu

Kehityksen päävaiheet on korostettu ja karakterisoitu ohjelmisto... Jokaiselle vaiheelle annetaan ja kuvataan keinot, joita voidaan käyttää vaiheen tavoitteiden saavuttamiseen.

1. Terminologia

Ennen kuin tarkastellaan kehitystyökaluja, joita voidaan käyttää ohjelmien luomiseen, on määriteltävä artikkelissa käytettävät peruskäsitteet, termit. Artikkelin aiheen mukaan peruskäsite meille tietysti on "ohjelmistokehitystyökalut". Ohjelmistokehityksen alalla tämä määritelmä voi kuulostaa seuraavasti:

Ohjelmistokehitystyökalut - joukko tekniikoita, menetelmiä, tekniikoita sekä joukko työkaluja (kääntäjät, sovellus- / järjestelmäkirjastot jne.), joita kehittäjä käyttää luomaan ohjelmakoodi Ohjelma, joka täyttää määritetyt vaatimukset.

Harkitsemalla tämä määritelmä termi "ohjelmistokehitys" kuulostaa tältä:

Ohjelmistokehitys – monimutkainen prosessi, jonka päätavoitteena on ohjelmakoodin luominen ja ylläpito, joka tarjoaa vaaditun luotettavuuden ja laadun. Ohjelmistokehityksen päätavoitteen saavuttamiseksi käytetään ohjelmistokehitystyökaluja.

2. Ohjelman kehittämisen eri vaiheissa käytetty käyttöomaisuus

Aihealueesta ja kehittäjille osoitetuista tehtävistä riippuen ohjelmien kehittäminen voi olla melko monimutkainen, vaiheittainen prosessi, johon sisältyy suuri määrä osallistujia ja erilaisia \u200b\u200bkeinoja. Korostaaksemme ohjelmistokehityksen päävaiheet voidaksemme määrittää, milloin ja missä tapauksissa mitä työkaluja käytetään. Seuraavat kehitysvaiheet ovat kiinnostavimpia tarkasteltavan asian ongelmien suhteen:

1. Sovelluksen suunnittelu.
2. Sovellusohjelmakoodin toteutus.
3. Sovelluksen testaaminen.

Kirjoitukseen liittyvät vaiheet jätetään tarkoituksella pois tekniset tiedot, aikataulujen aikataulut, budjetointi jne. Syynä tähän on, että näissä vaiheissa, harvoja poikkeuksia lukuun ottamatta, käytännössä ei käytetä erityisiä kehitystyökaluja.

2.1 Sovellusten suunnittelutyökalut

Sovelluksen suunnitteluvaiheessa, riippuen kehitetyn monimutkaisuudesta ohjelmistotuote, joka riippuu suoraan vaatimuksista, suoritetaan seuraavat suunnittelutehtävät:

1. Vaatimusanalyysi.
2. Tulevien ohjelmistojen arkkitehtuurin kehittäminen.
3. Laitteiden kehittäminen ovat ohjelmiston pääkomponentteja.
4. Käyttöliittymien asettelujen kehittäminen.

Suunnittelun tulos on yleensä ohjelmistosuunnitteluasiakirja tai. Vaatimusanalyysi suoritetaan yleensä systologian menetelmillä (analyysi ja synteesi) ottaen huomioon suunnittelijan asiantuntijakokemus. Analyysin tulos on yleensä mielekäs tai virallinen malli ohjelman toimintaprosessista. Prosessin monimutkaisuudesta riippuen nämä mallit voidaan rakentaa käyttämällä erilaisia \u200b\u200bmenetelmiä ja apuvälineet. Yleensä seuraavia merkintöjä käytetään yleensä kuvailemaan malleja (suluissa ovat ohjelmistojoita voidaan käyttää mallien luomiseen):

• BPMN (Vision 2003 + BPMN, AcuaLogic BPMN, Eclipse, Sybase Power Designer).
• Lohkokaaviot (Vision 2003 ja monet muut).
• ER-kaaviot (Visio 2003, ERWin, Sybase Power Designer ja monet muut).
• UML-kaaviot (Sybase Power Designer, Rationaalinen Rose ja monet muut).
• asettelut, matot mallit jne.

Joskus, kun kehitetyn ohjelmistotuotteen on tarkoitus automatisoida monimutkainen toiminto, analyysi (mallinnus) suoritetaan ennen kokoamista tekniset vaatimukset tulevaan tuotteeseen. Analyysin tulosten avulla voimme muotoilla kohtuulliset vaatimukset kehitetyn ohjelman tietylle toiminnallisuudelle ja laskea todellisen hyödyn kehitetyn tuotteen toteuttamisesta. Lisäksi käy toisin, että analyysin tulosten mukaan automaation alkuperäiset tavoitteet ja tavoitteet muuttuvat radikaalisti tai kehityksen ja toteutuksen tehokkuuden arvioinnin tulosten perusteella päätetään olla kehittämättä tuotetta.

Edellä olevan luettelon toisen ja kolmannen tehtävän tarkoituksena on kehittää tulevan järjestelmän malli (kuvaus), joka on ymmärrettävissä kooderille - ohjelmakoodin kirjoittavalle henkilölle. Tässä on erittäin tärkeää, mitä ohjelmointiparadigmaa (ohjelmointiparadigmaa on pidettävä myös kehitystyökaluna) tulisi käyttää ohjelmaa kirjoitettaessa. Seuraavat on mainittava esimerkkeinä pääparadigmoista:

• Toiminnallinen ohjelmointi;
• Jäsennelty ohjelmointi;
• Pakollinen ohjelmointi;
• Looginen ohjelmointi;
• Kohdekeskeinen ohjelmointi (prototyyppien valmistelu; luokkien käyttö; subjektiivinen ohjelmointi).

Hänen valintansa riippuu suurelta osin vallitsevista tottumuksista, kokemuksesta, perinteistä, työkalutkehitystiimin käytettävissä. Joskus kehitetty ohjelmistotuote on niin monimutkainen, että se ratkaisee useita tehtäviä eri komponentit järjestelmät käyttävät erilaisia \u200b\u200bparadigmoja. On huomattava, että yhden tai toisen lähestymistavan valinta asettaa rajoituksia keinoille, joita käytetään ohjelmakoodin täytäntöönpanovaiheessa. Tulos ongelman ratkaisemisesta voi lähestymistavasta riippuen olla (suluissa ovat ohjelmistotyökaluja, joita voidaan käyttää niiden hankkimiseen):

• luokkakaavio jne. (Ration Rose, Sybase PowerDisigner ja monet muut).
• kuvaus rakenteiden moduuleista ja niiden ohjelmiston käyttöliittymä (esim. Sybase PowerDisigner ja monet muut).

Käyttöliittymän asetteluiden kehittäminen merkitsee visuaalisen esityksen luomista siitä, kuinka tietyt videomuodot ja ikkunat näyttävät kehitetyssä sovelluksessa. Ratkaisu tähän ongelmaan perustuu suunnittelutyökalujen käyttöön, joita ei käsitellä tässä artikkelissa.

2.2 Työkalut ohjelmakoodin toteuttamiseen

Ohjelmakoodin toteutusvaiheessa suoritetaan koodaus yksittäiset komponentit suunnitellun teknisen projektin mukaisesti. Työkalut, joita voidaan käyttää, riippuvat suurelta osin suunnittelussa käytetyistä lähestymistavoista ja lisäksi valmistelun tasosta tekninen projekti... Siitä huolimatta ohjelmakoodin kehittämistyökalujen joukossa on korostettava seuraavia päätyökalutyyppejä (suluissa on esimerkkejä työkaluista): algoritmien menetelmät ja tekniikat.

• ohjelmointikielet (C ++, C, Java, C #, php ja monet muut);
• keinot luoda käyttöliittymä (MFC, WPF, QT, GTK + jne.)
• versionhallintatyökalut (cvs, svn, VSS).
• keinot suoritettavan koodin (MS Visual Studio, gcc ja monet muut).
• tietokannan hallintatyökalut (Oracle, MS SQL, FireBird, MySQL ja monet muut).
• virheenkorjaajat (MS Visual Studio, gdb jne.).

2.3 Ohjelman testaustyökalut

Testauksen päätehtävänä on varmistaa, että kehitetyn ohjelman toiminnallisuus täyttää alkuperäiset vaatimukset, sekä tunnistaa virheet, jotka ilmenevät suoraan tai epäsuorasti ohjelman käytön aikana. Testauksen pääteoksia ovat seuraavat:

• Vikatestaus ja palautus.
• Toiminnallinen testaus.
• Tietoturvatestaus.
• Vuorovaikutustestaus.
• Asennusprosessin testaus.
• Käytettävyyden testaus.
• Kokoonpanon testaus.
• Stressitestit.

Toimitetun työn suorittamiseen käytettäviä varoja ovat pääasiassa seuraavat:

• työkalut koodianalyysiin, profilointiin (Code Wizard - ParaSoft, Purify - Rational Softawre. Test Coverage - Semantic jne.);
• työkalut toimivuuden testaamiseen (TEST - Parasoft, QACenter - Compuware, Borland SilkTest jne.);
• työkalut suorituskyvyn testaamiseen (QACenter Performance - tietokoneohjelma jne.).

3. Päätelmä

Ohjelmistokehitysprosessi on monimutkainen prosessi, ja mitä työkaluja on käytettävä, riippuu suurelta osin kehittäjille osoitetuista tehtävistä. Kehitystehtävistä riippumatta työkaluja ei voida rajoittaa vain tiettyihin työkaluihin, vaan on myös tarpeen sisällyttää menetelmiä, tekniikoita, lähestymistapoja ja kaikkea, mitä käytetään annettujen vaatimusten mukaisen ohjelman luomiseen.

Myös katso :

Merkintä: Ohjelmistokehitysprosessin käsite. Yleinen prosessi... Nykyinen prosessi. Erityinen prosessi. Vakioprosessi... Prosessin parantaminen. Pull / Push-strategiat. Klassiset mallit prosessi: vesiputousmalli, spiraalimalli. Vaiheet ja toimet.

Tämän mallin etuna oli rajoitettu mahdollisuus palata mielivaltaiseen taaksepäin esimerkiksi testauksesta analyysiin, kehityksestä vaatimusten käsittelyyn jne. Todettiin, että tällaiset palautukset voivat katastrofaalisesti lisätä projektin kustannuksia ja sen ajoitusta. Esimerkiksi jos testauksen aikana havaitaan suunnittelu- tai analyysivirheitä, niiden korjaaminen johtaa usein järjestelmän täydelliseen muokkaamiseen. Tämä malli salli palata vain edelliseen vaiheeseen, esimerkiksi testauksesta koodaukseen, ohjelmistoista kritisoi tätä mallia aktiivisesti, käytännöllisesti katsoen jokainen asiaankuuluvien artikkeleiden ja oppikirjojen kirjoittaja. On yleisesti hyväksytty, että se ei heijasta ohjelmistokehityksen erityispiirteitä. Vesiputousmallin haitat ovat:

• vaiheiden ja toimintatyyppien tunnistaminen, mikä merkitsee kehityksen joustavuuden menetystä, erityisesti vaikeuksia iteratiivisen kehitysprosessin tukemisessa;
• vaatimus toimintavaiheen täydellisestä loppuun saattamisesta, tulosten yhdistämisestä yksityiskohtaisen alkuperäisen asiakirjan muodossa (tekninen tehtävä, suunnitteluspesifikaatio); kokemus ohjelmistokehityksestä osoittaa kuitenkin, että vaatimusten kehittämistä, järjestelmän suunnittelua jne. on mahdotonta suorittaa loppuun. - kaikki tämä voi muuttua; ja syyt tähän eivät ole vain se, että hankkeen ympäristö on liikkuva, vaan myös se, että monia päätöksiä ei voida määritellä ja muotoilla etukäteen tarkasti, vaan ne selkiytetään ja hienosäädetään vasta myöhemmin;
• kaikkien kehitystulosten integrointi tapahtuu lopussa, minkä seurauksena integraatio-ongelmat tuntevat itsensä liian myöhään;
• käyttäjät ja asiakas eivät voi tutustua järjestelmävaihtoehtoihin kehityksen aikana, ja näkevät tuloksen vasta loppupäässä; näin ollen ne eivät voi vaikuttaa järjestelmän luomisprosessiin, ja siksi väärinkäsitysten riski kehittäjien ja käyttäjien / asiakkaiden välillä kasvaa;
• malli ei kestä häiriöitä hankerahoituksessa tai uudelleenjaossa raha, aloitetulla kehityksellä ei itse asiassa ole vaihtoehtoja "matkan varrella".

mutta tämä malli käytetään edelleen käytännössä - pieniin hankkeisiin tai tyypillisten järjestelmien kehittämiseen, joissa iterointi ei ole niin kysyttyä. Sen avulla on kätevää seurata kehitystä ja toteuttaa projektin vaiheittainen hallinta. Tätä mallia käytetään usein myös offshore-projekteissa 1 Englannin offshore - offshore, laajennetussa tulkinnassa - yhden maan ulkopuolella. tuntipalkalla. Vesiputousmallista on tullut olennainen osa muita malleja ja menetelmiä, kuten MSF.

Spiraalimalli Bary Boehm ehdotti vuonna 1988 vesiputousmallin puutteiden poistamiseksi pääasiassa parempi hallinta riskejä. Tämän mallin mukaan tuotekehitys tapahtuu kierteellä, jonka jokainen kierros on tietty kehitysvaihe. Toisin kuin vesiputousmallissa, spiraalilla ei ole ennalta määrättyä ja pakollista kierrosjoukkoa, jokaisesta käännöksestä voi tulla viimeinen järjestelmän kehittämisvaiheessa, sen valmistuttua laaditaan suunnitelmat seuraavalle käännökselle. Lopuksi, silmukka on tarkalleen vaihe, eikä toiminnan tyyppi, kuten vesiputousmallissa, monien puitteissa erityyppisiä eli malli on kaksiulotteinen.

Silmukoiden järjestys voi olla seuraava: ensimmäisessä silmukassa tehdään päätös ohjelmiston luomisen tarkoituksenmukaisuudesta, seuraavassa silmukassa, laitteistovaatimukset , sitten järjestelmä on suunniteltu jne. Käämeillä voi olla muita merkityksiä.

Jokaisella silmukalla on seuraava rakenne (sektorit):

• määritetään projektin tavoitteet, rajoitteet ja vaihtoehdot;
• vaihtoehtojen arviointi, riskien arviointi ja ratkaiseminen; on mahdollista käyttää prototyyppejä (mukaan lukien prototyyppisarjojen luominen), järjestelmäsimulaatiota, visuaalista mallintamista ja spesifikaatioiden analysointia; keskittyminen hankkeen riskialttiimpiin osiin
• kehittäminen ja testaus - tässä vesiputousmalli tai muiden ohjelmistokehitysmallien ja -menetelmien käyttö on mahdollista;
• seuraavien iteraatioiden suunnittelu - tulokset, suunnitelmat ja resurssit myöhempää kehitystä varten analysoidaan, päätös (tai ei tehdä) uudesta kierroksesta; se analysoi onko järkevää jatkaa järjestelmän kehittämistä vai ei; kehitys voidaan keskeyttää esimerkiksi rahoituksen häiriöiden vuoksi; kierre malli avulla voit tehdä sen oikein.

Erillinen spiraali voi vastata joidenkin ohjelmistokomponenttien kehittämistä tai uusien muutosten tekemistä tuotteeseen. Siten mallilla voi olla kolmas ulottuvuus.

Spiraalimallia on epäkäytännöllistä soveltaa pieniriskisissä projekteissa, joiden budjetti on pieni, pieniin hankkeisiin. Lisäksi poissaolo hyvät keinot prototyyppien tekeminen voi myös tehdä spiraalimallista hankalaa.

Spiraalimalli ei ole löytänyt laajaa soveltamista teollisuudessa ja on pikemminkin tärkeä historiallisessa ja metodologisessa mielessä: se on ensimmäinen iteratiivinen malli, sillä on kaunis metafora - spiraali - ja kuten vesiputouksen mallia, sitä käytettiin myöhemmin muiden prosessimallien ja menetelmien luomiseen ohjelmistokehitykselle.

Ohjelmistotuotekehitys tuntee monia hyviä menetelmiä - toisin sanoen vakiintuneita parhaita käytäntöjä. Valinta riippuu projektin erityispiirteistä, budjetointijärjestelmästä, subjektiivisista mieltymyksistä ja jopa johtajan temperamentista. Tässä artikkelissa kuvataan menetelmiä, joita kohtaamme säännöllisesti Edisonissa.

1. "Vesiputouksen malli" (vesiputouksen malli tai "vesiputous")

Yksi vanhimmista käsittää vaiheiden peräkkäisen kulun, joista jokainen on suoritettava kokonaan ennen seuraavan aloitusta. Vesiputousmallia on helppo hallita projektia. Jäykkyytensä vuoksi kehitys on nopeaa, kustannukset ja aika ovat ennalta määriteltyjä. Mutta tämä on kaksiteräinen miekka. Vesiputousmalli antaa erinomaisia \u200b\u200btuloksia vain hankkeissa, joissa on selkeät ja ennalta määritellyt vaatimukset ja tapoja niiden toteuttamiseksi. Mitään ei voida ottaa askelta taaksepäin, testaus alkaa vasta kehityksen valmistuttua tai melkein valmistuneena. Tämän mallin mukaan kehitetyillä tuotteilla ilman tietoon perustuvaa valintaa voi olla virheitä (vaatimusten luetteloa ei voida muuttaa milloin tahansa), mikä tulee tunnetuksi vasta lopussa tiukan toimintajakson vuoksi. Muutoksen tekemisen kustannukset ovat korkeat, koska sen on alettava odottaa koko projektin valmistumista. Kiinteät kustannukset ovat kuitenkin usein suuremmat kuin lähestymistavan haitat. Luomisprosessissa havaittujen puutteiden korjaaminen on mahdollista ja vaatii kokemuksemme mukaan yhdestä kolmeen lisäsopimuksia sopimukseen pienen TK: n kanssa.

Vesiputousmallin avulla loimme monia hankkeita alusta alkaen, mukaan lukien vain teknisten eritelmien kehittäminen. Projektit, joista Habressa on kirjoitettu: keskikoko - pieni -.

Milloin vesiputousmenetelmää käytetään?

• Vasta kun vaatimukset tunnetaan, ymmärretään ja vahvistetaan. Ristiriitaisia \u200b\u200bvaatimuksia ei ole.
• Oikean pätevyyden omaavien ohjelmoijien saatavuudessa ei ole mitään ongelmaa.
• Suhteellisen pienissä projekteissa.

2. "V-malli"

Perinyt vaiheittaisen rakenteen vesiputousmallista. V-muotoinen malli soveltuu järjestelmiin, joissa sujuva toiminta on erityisen tärkeää. Esimerkiksi, sovellusohjelmat klinikoilla potilaan seurantaan, integroitu ohjelmisto turvatyynyjen hallintamekanismeja varten vuonna 2004 ajoneuvoja jne. Mallin piirteenä voidaan pitää sitä, että se on tarkoitettu tuotteen suunnittelulle, joka on jo suunnitteluvaiheessa. Testausvaihe tapahtuu samanaikaisesti vastaavan kehitysvaiheen kanssa, esimerkiksi koodituksen aikana kirjoitetaan yksikkötestit.

Esimerkki V-metodologiaan perustuvasta työstämme - mobiilisovellus eurooppalaiselle matkapuhelinoperaattorimikä säästää verkkovierailukuluja matkan aikana. Projekti toteutetaan selkeän teknisen eritelmän mukaisesti, mutta se sisältää merkittävän testausvaiheen: käyttöliittymän mukavuus, toiminnallinen, kuormitus ja integrointi mukaan lukien, mikä vahvistaa, että useita komponentteja on peräisin eri valmistajat toimivat yhdessä vakaasti, on mahdotonta varastaa rahaa ja lainoja.

Milloin käyttää V-mallia?

• Jos tuotteen perusteellinen testaus vaaditaan, V-malli oikeuttaa taustalla olevan idean: validointi ja todentaminen.
• Pienille ja keskisuurille hankkeille, joissa vaatimukset on määritelty selkeästi ja kiinteästi.
• Tarvittavan pätevyyden omaavien insinöörien, erityisesti testaajien, kanssa.

3. "Inkrementaalimalli" (inkrementaalimalli)

Inkrementaalimalleja käytetään, kun yksittäiset muutospyynnöt ovat selkeät ja ne voidaan helposti muodostaa ja toteuttaa. Projektissamme käytimme sitä DefView-lukijan ja sitten verkon luomiseen elektroniset kirjastot Vivaldi.

Kuvataan esimerkkinä yhden lisäyksen ydin. korvattu DefView. DefView kytketty yhteen asiakirjapalvelimeen ja voi nyt muodostaa yhteyden moniin. Laitoksen sivustoon, joka haluaa lähettää sisällön tietylle yleisölle, asennetaan tallennuspalvelin, joka käyttää asiakirjoja suoraan ja muuntaa ne haluttu muoto... Arkkitehtuurin juurielementti on ilmestynyt - keskitetty Vivaldi-palvelin, joka toimii yhtenä hakukone kaikissa eri laitoksiin asennetuissa tallennuspalvelimissa.

Milloin inkrementaalimallia käytetään?

• Kun järjestelmän perusvaatimukset on määritelty ja ymmärretty selkeästi. Samaan aikaan joitain yksityiskohtia voidaan parantaa ajan myötä.
• Markkinoiden lanseeraaminen vaaditaan aikaisin.
• On olemassa useita riskialttiita ominaisuuksia tai tavoitteita.

4. "RAD-malli" (nopea sovelluskehitysmalli tai nopea sovelluskehitys)

Malli nopea kehitys sovellukset sisältävät seuraavat vaiheet:

• Liiketoiminnan mallinnus: määritetään luettelo tietovirroista eri osastojen välillä.
• Tietomallinnus: Edellisessä vaiheessa kerättyjä tietoja käytetään määrittelemään tiedon levittämiseen tarvittavat objektit ja muut entiteetit.
• Prosessimallinnus: tietovirrat yhdistävät objekteja suunnittelutavoitteiden saavuttamiseksi.
• Rakenna sovellus: Käyttää automaattisen asennuksen työkaluja CAD-mallien muuntamiseen koodeiksi.
• Testaus: uudet komponentit ja liitännät testataan.

Sitä voidaan käyttää vain erittäin pätevien ja erikoistuneiden arkkitehtien kanssa. Hankkeen budjetti on suuri näiden asiantuntijoiden maksamiseen sekä valmiiden automatisoitujen kokoonpanotyökalujen kustannukset. RAD-malli voidaan valita luottavaisella tiedolla kohdealalle ja tarve tuottaa järjestelmä pikaisesti 2-3 kuukauden kuluessa.

5. "Ketterä malli" (joustava kehitysmenetelmä)

"Ketterässä" kehitysmenetelmässä asiakas voi jokaisen iteraation jälkeen tarkkailla tulosta ja ymmärtää, tyydyttääkö se sitä vai ei. Tämä on yksi joustavan mallin eduista. Sen haittoihin kuuluu se, että erityisten tulosten muotoilun puuttumisen vuoksi on vaikea arvioida työvoimakustannuksia ja kehitykseen tarvittavia kustannuksia. Äärimmäinen ohjelmointi (XP) on yksi ketterän mallin tunnetuimmista käytännön käyttötavoista.

Tämä tyyppi perustuu lyhyisiin päivittäisiin kokouksiin nimeltä "Scrum" ja säännöllisesti toistuviin kokouksiin (kerran viikossa, joka toinen viikko tai kerran kuukaudessa) "Sprint". Päivittäisissä kokouksissa tiimin jäsenet keskustelevat:

• raportti edellisen Scrumin jälkeen tehdystä työstä;
• luettelo tehtävistä, jotka työntekijän on suoritettava ennen seuraavaa kokousta;
• työn aikana kohdatut vaikeudet.

Milloin käyttää ketterää?

• Kun käyttäjien tarpeet muuttuvat jatkuvasti dynaamisessa liiketoiminnassa.
• Ketterät muutokset toteutetaan edullisemmin usein lisääntyvien lisäysten vuoksi.
• Toisin kuin vesiputousmalli, joustavassa mallissa projektin aloittamiseen riittää vain pieni suunnittelu.

6. "Iteratiivinen malli" (iteratiivinen tai iteratiivinen malli)

Kaavio osoittaa Mona Lisin iteratiivisen "kehityksen". Kuten näette, ensimmäisessä iteraatiossa on vain luonnos Mona Lisasta, toisessa - värit näkyvät, ja kolmas iteraatio lisää yksityiskohtia, kylläisyyttä ja täydentää prosessia. Inkrementaalimallissa tuotteen toiminnallisuus on rakennettu pala kerrallaan, tuote koostuu osista. Toisin kuin iteratiivinen malli, jokainen kappale on yhtenäinen elementti.

Esimerkki iteratiivisesta kehityksestä on äänentunnistus. Ensimmäinen tutkimus ja tieteellisen laitteen valmistelu alkoivat kauan sitten, ensin ajatuksissa, sitten - paperilla. Jokaisella uudella iteraatiolla tunnistuksen laatu on parantunut. Täydellistä tunnustusta ei kuitenkaan ole vielä saavutettu, joten ongelmaa ei ole vielä täysin ratkaistu.

Milloin iteratiivisen mallin käyttö on optimaalista?

• Vaatimukset loppujärjestelmä määriteltävä ja ymmärrettävä etukäteen.
• Projekti on suuri tai erittäin suuri.
• Suurin haaste on määriteltävä, mutta toteutuksen yksityiskohdat voivat kehittyä ajan myötä.

7. "Spiraalimalli"

Spiraalimalli on samanlainen kuin inkrementaalimalli, mutta painotetaan riskianalyysiä. Se toimii hyvin ratkaisemaan kriittisiä liiketoimintaongelmia, kun epäonnistuminen on ristiriidassa yrityksen toiminnan kanssa, tarvittaessa uusien tuotelinjojen edessä. tieteellinen tutkimus ja käytännön testaus.

Spiraalimallissa oletetaan 4 vaihetta jokaiselle silmukalle:

1. suunnittelu;
2. riskianalyysi;
3. design;
4. tuloksen arviointi ja, jos laatu on tyydyttävä, siirtyminen uudelle kierrokselle.

Tehdään yhteenveto

Dia näyttää eroja kahden yleisimmän menetelmän välillä.

Nykyaikaisessa käytännössä ohjelmistokehitysmallit ovat monivaiheisia. Kaikille projekteille, aloitusolosuhteille ja maksumalleille ei ole totta. Jopa meidän kaikkien rakastamaa ketterää ei voida soveltaa kaikkialla, koska jotkut asiakkaat eivät ole käytettävissä tai joustava rahoitus on mahdotonta. Menetelmät ovat osittain päällekkäisiä keinoissa ja ovat jonkin verran samanlaisia \u200b\u200btoistensa kanssa. Joitakin muita käsitteitä käytettiin vain omien kääntäjien mainostamiseen, eivätkä ne tuoneet mitään uutta käytäntöön.

Tietoja kehitystekniikoista:
.
.
.
.

Mitä menetelmiä käytät?

Nykyään monimutkaisen prosessin luominen ohjelmistosovellukset sitä on mahdotonta kuvitella jakamatta elinkaaren vaiheisiin. Ohjelman elinkaarella tarkoitetaan sarjaa vaiheita:

• Aihealueen analyysi ja teknisten eritelmien luominen (vuorovaikutus asiakkaan kanssa)
• Ohjelmarakenteen suunnittelu
• Koodaus (ohjelmakoodisarja projektidokumentaation mukaan)
• Testaus ja virheenkorjaus
• Ohjelman toteuttaminen
• Ohjelman tuki
• Kierrätys

Harkitse mallien visualisointikaavioiden tyyppejä (tämä on oltava, vaikka tyyppejä on paljon enemmän):

Käytä tapauskaaviota

Luokkakaavio

Tilakaavio (tilastokaavio)

Sekvenssikaavio

Yhteistyökaavio

Komponenttikaavio

Käyttöönottokaavio

Tämä päättää yleiskuvan erityisesti kaavioista ja suunnittelusta. On syytä huomata, että suunnitteluprosessista on jo pitkään tullut ohjelmistokehitysstandardi, mutta usein on käsiteltävä erinomaisesti kirjoitettua ohjelmaa, joka normaalin dokumentaation puuttuessa kasvaa tarpeettomilla sivutoiminnoilla, kainalosauvoilla, tulee hankalaksi ja menettää entisen laadun. \u003d (

Olen vakuuttunut siitä, että ohjelmoija on ennen kaikkea kooderi - hänen EI pidä kommunikoida asiakkaan kanssa, hänen EI pidä ajatella järjestelmän arkkitehtuuria, hänen ei tule keksiä käyttöliittymää ohjelmalle, hänen pitäisi vain koodata - toteuttaa algoritmeja, toiminnallisuutta, ulkomuoto, käytettävyys, mutta ei enempää…. Suunnittelijan tulisi aloittaa abstrakteista kaavioista (kuvaavat aihealue) kaavioihin, jotka esittävät tietojen rakennetta, luokkia ja niiden vuorovaikutuksen prosesseja, kuvaavat kaiken yksityiskohtaisesti askel askeleelta. Toisin sanoen työn monimutkaisuuden ja suunnittelijan palkan tulisi olla suuruusluokkaa suurempi kuin ohjelmoijan \u003d\u003d kooderin. Anteeksi sedition ...