Ensimmäisessä osassa valitsimme vertailla ohjelmistokehitysmenetelmiä, kuten metodologian suhdetta iteratiiviseen kehitykseen ja muodollisuusastetta työmateriaalien suunnittelussa ja yleensä kehitysprosessissa. Tässä osassa käytämme näitä indikaattoreita vertaamaan tunnetuimpia ohjelmistokehitysmenetelmiä.

Miten siitä tulee...

Valitettavasti tämä luokka on vaikein kuvata - se sisältää loppujen lopuksi sekä tuotteen aloittelijan kiihkeän heittäytymisen, joka yrittää saada päätökseen ensimmäistä projektiaan hinnalla millä hyvänsä, että varsin kypsät ja vakiintuneet menetelmät, jotka ovat imeneet monia vuosia erilaisten kehitystiimien monipuolinen kokemus ja ne on jopa kuvattu sisäisissä määräyksissä Koska ihmiset, jotka pystyvät kehittämään oman metodologiansa, voivat pääsääntöisesti itse arvioida sitä iteratiivisuuden ja formalisoinnin suhteen, keskitymme aloittelijoihin. Valitettavasti tämä tarkoittaa useimmiten sitä, että kehittämissääntöjä joko ei ole ollenkaan tai ne on kehitetty ja hyväksytty, mutta niitä ei noudateta. Tällaisissa olosuhteissa on luonnollista, että kehityksen formalismi on erittäin alhainen. Joten kaikki on selvää tämän kanssa.

Kehitys "Kuinka siitä tulee"

Entä iteratiivinen lähestymistapa? Valitettavasti sitä ei yleensä käytetä tällaisissa projekteissa. Ensinnäkin siksi, että se olisi mahdollistanut hankkeen arvioimisen jo ensimmäisissä iteraatioissa äärimmäisen kyseenalaisena ja vaativan kiireellistä ylemmän johdon väliintuloa järjestyksen palauttamiseksi. Itse asiassa iteratiivisessa projektissa ohjelmoijan perinteinen vastaus, että hänellä on kaikki 90% valmiina, kestää vain ensimmäisen iteroinnin loppuun asti...

Rakenteelliset metodologiat

Rakenteelliset metodologiat

Rakenteelliset menetelmät ovat joukko menetelmiä, jotka on yleensä kehitetty jo ennen oliokielten laajaa käyttöä. Kaikki ne sisältävät vesiputouksen kehittämisen. Vaikka, kuten kävi ilmi, jopa tuossa artikkelissa, jota usein mainitaan vesiputouslähestymistavan ensimmäisenä esittelynä, sanottiin, että on suositeltavaa aloittaa projekti prototyypin kehittämisellä, eli suorittaa vähintään kaksi iteraatiota.

Kuitenkin näiden metodologioiden perustana on johdonmukainen siirtyminen työstä työhön ja seuraavan vaiheen tulosten (asiakirjojen) siirtäminen seuraavan vaiheen osallistujille.

Lisäksi kaikki nämä menetelmät vaativat erittäin formalisoitua lähestymistapaa, vaikka niistä löytyy lausuntoja kohtuullisesta määrästä dokumentaatiota. Yksi ei-ilmeisistä esimerkeistä siitä, että ohjelmistokehitysmetodologiat ovat kehittyneet muualla kuin lännessä, on lainaus maassamme 1980-luvun alussa julkaistusta kirjasta, jossa todetaan, että ohjelmointitehtävän formalisaatioaste tulee määrittää sen perusteella, kuinka hyvin. analyytikko ja ohjelmoija. Ja tämä huolimatta siitä, että kirjan aiheena oli melko kriittisten, kuten niitä nykyään kutsutaan, järjestelmien kehittäminen, joissa virheet johtavat vakaviin menetyksiin tai jopa katastrofeihin.

Ketterät menetelmät

Ketterät metodologiat perustuvat kymmeneen periaatteeseen, joista nimetään vain ne, jotka määrittävät näiden metodologioiden arvioinnin valittujen parametrien mukaan:

• tärkeintä on tyydyttää asiakas ja toimittaa hänelle tuote mahdollisimman pian;
• uusien tuotejulkaisujen tulisi ilmestyä muutaman viikon tai enintään kuukauden välein;
• tehokkain tapa siirtää tietoa kehitystyön osallistujille ja heidän välillään on henkilökohtainen viestintä;
• työohjelma on paras indikaattori kehityksen edistymisestä.

Nämä menetelmät ovat siis selkeästi keskittyneet iteratiiviseen ohjelmistokehitykseen ja prosessin minimaaliseen formalisointiin. Toisen kohdan osalta on kuitenkin tarpeen tehdä varaus: nimetyt menetelmät keskittyvät tietylle hankkeelle hyväksyttävään formalisoinnin vähimmäistasoon. Ainakin yhdessä joustavien ryhmään kuuluvista metodologioista - Crystal - on modifikaatioita, jotka on suunniteltu suorittamaan prosesseja eri osallistujamäärillä ja kehitettävän ohjelmiston eri kriittisyyden kanssa (ohjelmiston kriittisyyden määräävät mahdolliset virheiden seuraukset, jotka voivat vaihtelevat pienistä taloudellisista tappioista virheiden korjaamiseen ennen katastrofaalisia). Jotta lisävertailu joustaviin menetelmiin ei olisi turhaa, annamme lyhyen kuvauksen useista niistä.

eXtreme Programming tai XP (Extreme Programming)

Kent Beckin, Ward Cunninghamin ja Ron Jeffriesin kehittämä XP-metodologia on nykyään tunnetuin ketteristä menetelmistä. Joskus "ketterien metodologioiden" käsite tunnistetaan suoraan tai implisiittisesti XP:hen, joka saarnaa kommunikaatiota, yksinkertaisuutta, palautetta ja rohkeutta. Sitä kuvataan käytäntöjen sarjana: suunnittelupeli, lyhyet julkaisut, metaforat, yksinkertainen suunnittelu, uudelleenmuodostus, testi eteenpäin -kehitys, pariohjelmointi, jaettu koodin omistaminen, 40 tunnin työviikot, aina paikalla oleva asiakkaan läsnäolo ja koodistandardit . Kiinnostus XP:tä kohtaan kasvoi alhaalta ylöspäin – kehittäjiltä ja testaajilta, joita tuskallinen prosessi, dokumentaatio, mittarit ja muu formalismi kiduttivat. He eivät hylänneet kurinalaisuutta, mutta eivät halunneet turhaan noudattaa muodollisia vaatimuksia ja etsivät uusia, nopeita ja joustavia lähestymistapoja laadukkaiden ohjelmien kehittämiseen.

XP:tä käytettäessä huolellinen alustava ohjelmistosuunnittelu korvataan toisaalta asiakkaan jatkuvalla läsnäololla tiimissä, joka on valmis vastaamaan kaikkiin kysymyksiin ja arvioimaan minkä tahansa prototyypin, ja toisaalta säännöllisillä koodiversioilla (ns. refaktorointi). Huolellisesti kommentoitu koodi katsotaan hankedokumentaation perustaksi. Metodologiassa kiinnitetään paljon huomiota testaukseen. Pääsääntöisesti jokaiselle uudelle menetelmälle kirjoitetaan ensin testi, jonka jälkeen varsinaista menetelmäkoodia kehitetään, kunnes testi alkaa onnistua. Nämä testit on tallennettu testipaketteihin, jotka suoritetaan automaattisesti koodin muutoksen jälkeen.

Vaikka pariohjelmointi ja 40 tunnin työviikko ovat XP:n ehkä tunnetuimpia ominaisuuksia, ne ovat luonteeltaan tukevia ja edistävät kehittäjien korkeaa tuottavuutta ja vähentävät kehitysvirheitä.

Kristallinkirkas

Crystal on joukko menetelmiä, jotka määrittävät kehitysprosessin vaaditun formalisaatioasteen osallistujien lukumäärän ja tehtävien kriittisyyden mukaan.

Crystal Clear -menetelmä on suorituskyvyltään heikompi kuin XP, mutta se on erittäin helppokäyttöinen. Sen toteuttaminen vaatii vain vähän vaivaa, koska se keskittyy ihmisten tapoihin. Tämän metodologian uskotaan kuvaavan ohjelmistokehityksen luonnollista järjestystä, joka muodostuu riittävän pätevissä tiimeissä, jos he eivät ole mukana jonkin muun metodologian kohdennetussa toteutuksessa.

Crystal Clearin tärkeimmät ominaisuudet:

• iteratiivinen inkrementaalinen kehitys;
• automaattinen regressiotestaus;
• käyttäjiä pyydetään osallistumaan aktiivisesti hankkeeseen;
• hankkeen osallistujat määrittelevät dokumentaation koostumuksen;
• Tyypillisesti käytetään koodiversion hallintatyökaluja.

Crystal Clearin lisäksi Crystal-perhe sisältää useita muita menetelmiä, jotka on suunniteltu käsittelemään suurempia tai kriittisempiä projekteja. Niillä on hieman tiukemmat vaatimukset dokumentaation laajuudelle ja tukitoimenpiteille, kuten muutos- ja versionhallintaan.

Ominaisuusvetoinen kehitys

Feature Driven Development (FDD) toimii järjestelmän funktion tai ominaisuuden (ominaisuuden) käsitteen kanssa, mikä on melko lähellä RUP:ssa käytettyä käyttötapauksen käsitettä. Ehkä merkittävin ero on lisärajoitus: "Jokaisen toiminnon on oltava mahdollista toteuttaa enintään kahdessa viikossa." Eli jos käyttötapaus on tarpeeksi pieni, sitä voidaan pitää funktiona, ja jos se on suuri, se on jaettava useisiin suhteellisen itsenäisiin toimintoihin.

FDD sisältää viisi prosessia, joista kaksi viimeistä toistetaan jokaiselle toiminnolle:

• yleisen mallin kehittäminen;
• tarvittavien järjestelmän toimintojen luettelon laatiminen;
• kunkin toiminnon työn suunnittelu;
• toimintojen suunnittelu;
• toiminnallinen rakenne.

Projektin parissa työskentelyyn kuuluu toistuvia koontiversioita, ja se on jaettu iteraatioihin, joista jokainen toteutetaan käyttämällä tiettyä toimintosarjaa.

FDD:n kehittäjät jaetaan "luokkamestareihin" ja "pääohjelmoijiin". Pääohjelmoijat ottavat mukana olevien luokkien omistajat mukaan seuraavan kiinteistön työhön. Vertailun vuoksi XP:ssä ei ole henkilöitä, jotka ovat vastuussa luokista tai menetelmistä.

Yleiset ominaisuudet

Joustavien menetelmien luettelo on tällä hetkellä melko laaja. Siitä huolimatta kuvaamamme menetelmät antavat erittäin täydellisen kuvan koko perheestä.

Lähes kaikki joustavat metodologiat käyttävät iteratiivista lähestymistapaa, jossa vain rajoitettu määrä seuraavan julkaisun julkaisuun liittyvää työtä suunnitellaan yksityiskohtaisesti.

Lähes kaikki joustavat metodologiat keskittyvät kaikkein epämuodollisimpiin kehittämiseen. Jos ongelma voidaan ratkaista normaalin keskustelun aikana, on parempi tehdä juuri niin. Lisäksi paperilla tai sähköisellä asiakirjalla tehty päätös on tarpeen virallistaa vain silloin, kun sitä ei voida tehdä ilman sitä.

Ketterät menetelmät

GOST standardit

GOST:t, kuten seuraavassa osiossa kuvatut CMM-mallivaatimukset, eivät ole menetelmiä. Ne eivät pääsääntöisesti kuvaile itse ohjelmistokehitysprosesseja, vaan vain muotoilevat prosesseille tiettyjä vaatimuksia, jotka eri metodologioilla eriasteisesti täyttyvät. Vaatimusten vertailu samoilla kriteereillä, joilla vertaamme menetelmiä, auttaa sinua välittömästi päättämään, mitä menetelmiä tulisi käyttää, jos sinun on suoritettava kehitystä GOST:n mukaisesti.

Tällä hetkellä Venäjällä vanhat 19. ja 34. sarjan GOST:t ja uudemmat GOST R ISO IEC 122207 -sarjat ovat voimassa 19. ja 34. sarjan GOST:t, jotka keskittyvät tiukasti ohjelmistokehitykseen. Näiden GOST:ien mukainen kehitys tapahtuu vaiheittain, joista jokainen sisältää tiukasti määritellyn työn toteuttamisen ja päättyy melko suuren määrän erittäin muodollisia ja laajoja asiakirjoja julkaisemiseen. Siten näiden standardien välitön tiukka noudattaminen ei johda pelkästään vesiputouslähestymistapaan, vaan varmistaa myös kehityksen erittäin korkean virallistamisen.

GOST-vaatimukset

GOST 12207, toisin kuin 19. ja 34. sarjan standardeja, kuvaa ohjelmistokehitystä joukona pää- ja apuprosesseja, jotka voivat toimia alusta projektin loppuun. Elinkaarimalli voidaan valita projektin ominaisuuksien perusteella. Näin ollen tämä GOST ei nimenomaisesti kiellä iteratiivisen lähestymistavan käyttöä, mutta ei myöskään nimenomaisesti suosittele sen käyttöä. GOST 12207 on myös joustavampi kehitysprosessin muodollisuusvaatimusten suhteen. Se sisältää vain ohjeet tarpeesta dokumentoida kaikkien prosessien tärkeimmät tulokset, mutta siinä ei ole luetteloita vaadituista asiakirjoista ja ohjeita niiden sisällöstä.

Näin ollen GOST 12207 mahdollistaa iteratiivisen ja vähemmän muodollisen ohjelmistokehityksen.

Kehitysprosessien kypsyysmallit (CMM, CMMI)

Valtion ja kansainvälisten standardien lisäksi kehitysprosessin sertifioinnissa on useita lähestymistapoja. Tunnetuimmat niistä Venäjällä ovat ilmeisesti CMM ja CMMI.

CMM (Capability Maturity Model) on ohjelmistojen luontiprosessien kypsyysmalli, joka on suunniteltu arvioimaan tietyn yrityksen kehitysprosessin kypsyysastetta. Tämän mallin mukaan kehitysprosessin kypsyysasteita on viisi. Ensimmäinen taso vastaa kehitystä "sellaisena kuin se tapahtuu", kun kehittäjät lähestyvät jokaista projektia kuin se olisi saavutus. Toinen vastaa enemmän tai vähemmän vakiintuneita prosesseja, jolloin voit luottaa kohtuullisella varmuudella projektin myönteiseen lopputulokseen. Kolmas vastaa kehitettyjen ja hyvin kuvattujen prosessien läsnäoloa, joita käytetään kehityksessä, ja neljäs vastaa aktiivista mittareiden käyttöä johtamisprosessissa tavoitteiden asettamiseen ja niiden saavuttamisen seuraamiseen. Lopuksi viides taso viittaa yrityksen kykyyn optimoida prosessi tarpeen mukaan.

CMM- ja CMMI-vaatimukset

CMM:n tulon jälkeen alettiin kehittää erikoistuneita kypsyysmalleja tietojärjestelmien luomiseen, toimittajan valintaprosessiin ja joihinkin muihin. Niiden pohjalta kehitettiin integroitu CMMI-malli (Capability Maturity Model Integration). Lisäksi CMMI yritti voittaa CMM:n tuolloin ilmenneet puutteet - prosessien muodollisten kuvausten roolin liioittelua, kun tietyn dokumentaation olemassaolo arvioitiin paljon korkeammalle kuin vain vakiintunut, mutta kuvaamaton. käsitellä. CMMI keskittyy kuitenkin myös hyvin formalisoidun prosessin käyttöön.

Näin ollen CMM- ja CMMI-mallien perustana on kehitysprosessin formalisointi. Ne pyrkivät kehittäjiin toteuttamaan määräyksissä ja ohjeissa yksityiskohtaisesti kuvatun prosessin, joka puolestaan ​​edellyttää laajan projektidokumentaation kehittämistä asianmukaista valvontaa ja raportointia varten.

CMM:n ja CMMI:n yhteys iteratiiviseen kehitykseen on epäsuorampi. Muodollisesti kumpikaan ei esitä erityisiä vaatimuksia vesiputouksen tai iteratiivisen lähestymistavan noudattamiselle. Joidenkin asiantuntijoiden mukaan CMM on kuitenkin yhteensopivampi vesiputouslähestymistavan kanssa, kun taas CMMI mahdollistaa myös iteratiivisen lähestymistavan käytön.

RUP

Tietenkin RUP on iteratiivinen menetelmä. Vaikka pakollista vaatimusta kaikkien vaiheiden suorittamisesta tai tietyn vähimmäismäärän iteraatioita ei ole virallisesti ilmoitettu missään RUP:ssa, on koko lähestymistapa keskittynyt siihen, että niitä on melko paljon. Iteraatioiden rajallinen määrä ei anna mahdollisuutta hyödyntää RUP:n kaikkia etuja täysimääräisesti. Samalla RUP:ia voidaan käyttää myös käytännössä vesiputousprojekteissa, joissa itse asiassa on vain pari iteraatiota: yksi "Build"-vaiheessa ja toinen "Transfer"-vaiheessa. Muuten, vesiputousprojekteissa tätä iteraatioiden määrää todella käytetään. Järjestelmän testaamiseen ja koekäyttöön kuuluukin sitten korjausten tekeminen, mikä voi sisältää tiettyjä analysointiin, suunnitteluun ja kehittämiseen liittyviä toimia, eli itse asiassa ne ovat toinen läpikulku kaikissa kehitysvaiheissa.

RUP-metodologia

Mitä tulee metodologian muodollisuuteen, RUP tarjoaa käyttäjälle erittäin laajan valikoiman mahdollisuuksia. Jos teet kaiken työn ja tehtävät, luot kaikki artefaktit ja suoritat kaikki arvioinnit melko muodollisesti (virallisen arvioijan kanssa, valmistelemalla täydellistä arviota sähköisen tai paperillisen asiakirjan muodossa jne.), RUP voi osoittautua erittäin muodolliseksi, raskaaksi menetelmäksi. Samaan aikaan RUP antaa sinun kehittää vain niitä esineitä ja suorittaa vain ne työt ja tehtävät, jotka ovat tarpeen tietyssä projektissa. Ja valitut artefaktit voidaan suorittaa ja tarkastella mielivaltaisilla muodollisuuksilla. Voit vaatia jokaisen asiakirjan yksityiskohtaista käsittelyä ja huolellista toteutusta, yhtä huolellisesti laaditun ja toteutetun katsauksen toimittamista ja jopa vanhan käytännön mukaisesti jokaisen sellaisen katsauksen hyväksymistä yrityksen tieteelliseltä ja tekniseltä neuvostolta. Tai voit rajoittua sähköpostiin tai luonnokseen paperilla. Lisäksi on aina yksi mahdollisuus: muodostaa dokumentti päässäsi, eli pohtia asiaa ja tehdä rakentava päätös. Ja jos tämä päätös koskee vain sinua, rajoita itsesi esimerkiksi ohjelmakoodin kommenttiin.

Näin ollen RUP on iteratiivinen metodologia, jossa on erittäin laaja valikoima mahdollisia ratkaisuja kehitysprosessin formalisoinnissa.

Tehdään yhteenveto artikkelin toisesta osasta. RUP, toisin kuin useimmat muut menetelmät, antaa sinun valita laajasti kehitysprosessin formalisaatio- ja iteratiivisuuden asteen projektin ja kehittyvän organisaation ominaisuuksien mukaan.

Keskustelemme seuraavassa osassa, miksi tämä on niin tärkeää.

Nykyään ohjelmistosuunnittelussa EIS-ohjelmistojen kehittämiseen on kaksi pääasiallista lähestymistapaa, joiden perustavanlaatuinen ero johtuu järjestelmien erilaisista hajotusmenetelmistä. Ensimmäistä lähestymistapaa kutsutaan toiminnalliseksi modulaariseksi tai rakenteelliseksi. Se perustuu funktionaalisen hajonnan periaatteeseen, jossa järjestelmän rakennetta kuvataan sen toimintojen hierarkian ja yksittäisten toiminnallisten elementtien välisen tiedonsiirron avulla. Toinen, oliolähtöinen lähestymistapa käyttää objektien hajottamista. Tässä tapauksessa järjestelmän rakennetta kuvataan kohteiden ja niiden välisten yhteyksien avulla ja järjestelmän käyttäytymistä objektien välisen viestien vaihdon avulla.

Eli EIS-ohjelmistokehityksen rakenteellisen lähestymistavan ydin on sen hajoamisessa (jakamisessa) automatisoituihin toimintoihin: järjestelmä on jaettu toiminnallisiin alajärjestelmiin, jotka puolestaan ​​on jaettu alitoimintoihin, ne tehtäviin ja niin edelleen. erityisiä menettelyjä. Samalla automatisoitu järjestelmä ylläpitää kokonaisvaltaista näkemystä, jossa kaikki komponentit on kytketty toisiinsa. Kun järjestelmää kehitetään "alhaalta ylöspäin", yksittäisistä tehtävistä koko järjestelmään, eheys katoaa ja ongelmia syntyy kuvattaessa yksittäisten komponenttien informaatiovuorovaikutusta.

Kaikki yleisimmät rakenteellisen lähestymistavan menetelmät perustuvat useisiin yleisiin periaatteisiin. Perusperiaatteet ovat:

hajota ja hallitse -periaate (katso kohta 2.1.1);

hierarkkisen järjestyksen periaate on periaate, jossa järjestelmän komponentit järjestetään hierarkkisiksi puurakenteiksi lisäämällä uusia yksityiskohtia jokaiselle tasolle.

Kahden perusperiaatteen korostaminen ei tarkoita, että loput periaatteet olisivat toissijaisia, koska minkä tahansa niistä huomiotta jättäminen voi johtaa arvaamattomiin seurauksiin (mukaan lukien koko projektin epäonnistuminen). Tärkeimmät näistä periaatteista ovat:

abstraktion periaate - järjestelmän olennaisten näkökohtien korostaminen ja merkityksettömän poistaminen;

johdonmukaisuuden periaate - järjestelmän elementtien pätevyys ja johdonmukaisuus;

Tietojen strukturoinnin periaate – tietojen tulee olla jäsenneltyä ja hierarkkisesti järjestettyä.

Rakenteellisessa lähestymistavassa käytetään pääasiassa kahta työkaluryhmää, jotka kuvaavat järjestelmän toiminnallista rakennetta ja tietojen välisiä suhteita. Jokainen työkaluryhmä vastaa tietyntyyppisiä malleja (kaavioita), joista yleisimmät ovat:

DFD (Data Flow Diagrams) - tietovuokaaviot;

SADT (Structured Analysis and Design Technique - rakenneanalyysin ja suunnittelun menetelmä) - mallit ja vastaavat toimintakaaviot;

ERD (Entity-Relationship Diagrams) - entiteetti-suhdekaaviot.

Tietovuokaaviot ja entiteetti-suhdekaaviot ovat yleisimmin käytettyjä mallityyppejä CASE-työkaluissa.

Listattujen kaavioiden erityinen muoto ja niiden suunnitelmien tulkinta riippuu ohjelmiston elinkaaren vaiheesta.

Ohjelmistovaatimusten muodostusvaiheessa SADT-malleja ja DFD:tä käytetään "AS-IS"- ja "TO-BE"-mallin rakentamiseen, mikä kuvastaa organisaation liiketoimintaprosessien olemassa olevaa ja ehdotettua rakennetta ja niiden välistä vuorovaikutusta ( SADT-mallien käyttö rajoittuu pääsääntöisesti vain tähän vaiheeseen, koska niitä ei alun perin ollut tarkoitettu ohjelmistosuunnitteluun). ERD:n avulla organisaatiossa käytettävän datan kuvaus toteutetaan käsitteellisellä tasolla tietokannan toteutustyökaluista (DBMS) riippumatta.

Suunnitteluvaiheessa DFD:t kuvaavat suunnitellun ohjelmistojärjestelmän rakennetta, ja niitä voidaan jalostaa, laajentaa ja täydentää uusilla malleilla. Vastaavasti ERD:itä jalostetaan ja täydennetään uusilla rakenteilla, jotka kuvaavat tietojen esittämistä loogisella tasolla, joka sopii tietokantaskeeman myöhempään luomiseen. Näitä malleja voidaan täydentää ohjelmistojärjestelmän arkkitehtuuria kuvaavilla kaavioilla, ohjelman lohkokaavioilla, näyttömuotojen ja valikkojen hierarkialla jne.

Listatut mallit yhdessä tarjoavat täydellisen kuvauksen EIS-ohjelmistosta riippumatta siitä, onko järjestelmä olemassa vai vasta kehitetty. Kaavioiden koostumus kussakin tapauksessa riippuu järjestelmän monimutkaisuudesta ja sen kuvauksen tarpeellisesta täydellisyydestä.

Useimpien tässä luvussa annettujen kaavioesimerkkien aihealue on Venäjän federaation verojärjestelmä, jonka täydellisin kuvaus sisältyy Venäjän federaation verolakiin. Venäjän federaation verojärjestelmässä käytetyillä tietotekniikoilla on tiettyjä ominaisuuksia.

1. Koodaus

Ohjelmiston kehitysvaiheessa suoritetaan seuraavat päätoiminnot: koodaus; testaus; PP-apujärjestelmän kehittäminen; käyttäjädokumentaation luominen; ohjelmistoversion luominen ja asennus,

Koodaus on prosessi, jossa korkean ja matalan tason suunnittelutulokset muunnetaan valmiiksi ohjelmistotuotteeksi. Toisin sanoen koodattaessa käännetty ohjelmistomalli kuvataan valitulla ohjelmointikielellä, joka voi olla mikä tahansa olemassa olevista kielistä. Kielen valinta tehdään joko asiakkaan pyynnöstä tai ottaen huomioon ratkaistava ongelma ja kehittäjien henkilökohtainen kokemus.

Koodattaessa on noudatettava valitun kielen standardia, esimerkiksi C-kielelle se on ANSI C ja C++:lle ISO/IEC 14882 “Standard for the C++ Programming Language”.

Yleisesti hyväksytyn ohjelmointikielen standardin lisäksi yritys voi kehittää myös omia lisävaatimuksia ohjelmien kirjoittamisen sääntöihin. Ne koskevat pääasiassa ohjelman tekstin muotoilun sääntöjä.

Vakio- ja yrityssääntöjä noudattamalla voit luoda oikein toimivan, helposti luettavan ja muiden kehittäjien ymmärrettävän ohjelman, joka sisältää tiedot kehittäjästä, luomispäivämäärän, nimen ja tarkoituksen sekä tarvittavat tiedot konfiguraatioiden hallintaan.

Koodausvaiheessa ohjelmoija kirjoittaa ohjelmia ja testaa niitä itse. Tämän tyyppistä testausta kutsutaan yksikkötestaukseksi. Kaikki ohjelmistotestaukseen liittyvät asiat käsitellään luvussa. 10, tässä kuvataan myös ohjelmistokehitysvaiheessa käytettävä testaustekniikka. Tätä tekniikkaa kutsutaan testaukseksi "lasilaatikko" (lasilaatikko); joskus sitä kutsutaan myös testaamiseksi "valkoinen laatikko" (whitebox) toisin kuin klassinen "mustan laatikon" käsite.

Mustan laatikon testauksessa ohjelmaa käsitellään objektina, jonka sisäistä rakennetta ei tunneta. Testaaja syöttää tietoja ja analysoi tuloksen, mutta hän ei tiedä tarkalleen kuinka ohjelma toimii. Testejä valitessaan asiantuntija etsii hänen näkökulmastaan ​​kiinnostavia syöttötietoja ja olosuhteita, jotka voivat johtaa epästandardeihin tuloksiin. Häntä kiinnostavat ensisijaisesti ne kunkin syöttötietoluokan edustajat, joissa testattavan ohjelman virheitä todennäköisimmin tapahtuu.

Kun testataan "lasilaatikkoa", tilanne on täysin erilainen. Testaaja (tässä tapauksessa ohjelmoija itse) kehittää testejä perustuen lähdekoodin tuntemukseen, johon hänellä on täysi pääsy. Tämän seurauksena hän saa seuraavat edut.

1. Testauksen suunta. Ohjelmoija voi testata ohjelmaa osissa, kehittää erityisiä testialirutiineja, jotka kutsuvat testattavan moduulin ja välittävät siihen ohjelmoijaa kiinnostavat tiedot. On paljon helpompaa testata erillistä moduulia "lasilaatikona".

2. Täysi koodi kattavuus. Ohjelmoija voi aina määrittää, mitkä koodifragmentit toimivat kussakin testissä. Hän näkee, mitkä muut koodin osat jäävät testaamatta, ja voi valita ehdot, joissa niitä testataan. Seuraavassa kuvataan, kuinka voit seurata suoritettujen testien koodipeittoastetta.

3. Kyky hallita komentojen kulkua. Ohjelmoija tietää aina, mikä toiminto tulee suorittaa ohjelmassa seuraavaksi ja mikä sen nykyinen tila tulee olla. Selvittääkseen, toimiiko ohjelma niin kuin hän luulee, ohjelmoija voi sisällyttää virheenkorjauskomentoja, jotka näyttävät tietoja sen suorituksesta, tai käyttää erityistä ohjelmistotyökalua, jota kutsutaan debuggeriksi. Debuggeri voi tehdä paljon hyödyllistä: valvoa ja muuttaa ohjelman komentojen suoritusjärjestystä, näyttää muuttujiensa sisällön ja niiden osoitteet muistissa jne.

4. Kyky valvoa tietojen eheyttä. Ohjelmoija tietää, minkä ohjelman osan tulee muuttaa kutakin tietoelementtiä. Tarkkailemalla tietojen tilaa (samalla debuggerilla) hän voi tunnistaa virheet, kuten väärien moduulien muuttamisen, niiden virheellisen tulkinnan tai epäonnistuneen organisoinnin.

5.Sisäisten rajapisteiden visio. Lähdekoodissa näkyvät ne ohjelman rajapisteet, jotka ovat piilossa ulkopuolelta. Esimerkiksi tietyn toiminnon suorittamiseen voidaan käyttää useita täysin erilaisia ​​​​algoritmeja, ja ilman koodia katsomatta on mahdotonta määrittää, kumman ohjelmoija valitsi. Toinen yleinen esimerkki on ylivuoto-ongelma puskurissa, jota käytetään syöttötietojen tilapäiseen tallentamiseen. Ohjelmoija voi heti kertoa, millä datamäärällä puskuri tulee yli, eikä hänen tarvitse tehdä tuhansia testejä.

6. Testausmahdollisuus valitun algoritmin mukaan. Erittäin monimutkaisia ​​laskentaalgoritmeja käyttävän tietojenkäsittelyn testaus voi vaatia erityistekniikoita. Klassisia esimerkkejä ovat matriisimuunnos ja tietojen lajittelu. Testaajan, toisin kuin ohjelmoijan, on tiedettävä tarkalleen, mitä algoritmeja käytetään, joten hänen on käännyttävä erikoiskirjallisuuden puoleen.

Lasilaatikoiden testaus on osa ohjelmointiprosessia. Ohjelmoijat tekevät tätä työtä koko ajan, he testaavat jokaista moduulia sen kirjoittamisen jälkeen ja sitten uudelleen integroituaan sen järjestelmään.

Yksikkötestauksessa voit käyttää joko rakenteellista tai toiminnallista testaustekniikkaa tai molempia.

Rakenteellinen testaus on eräänlainen lasilaatikkotestaus. Sen pääideana on testattavan ohjelmistopolun oikea valinta. Päinvastoin kuin hän toimiva testaus kuuluu black box -testauksen luokkaan. Jokainen ohjelman toiminto testataan syöttämällä sen syöttötiedot ja analysoimalla sen tulos. Samaan aikaan ohjelman sisäinen rakenne otetaan hyvin harvoin huomioon.

Vaikka rakennetestauksella on paljon vahvempi teoreettinen perusta, useimmat testaajat suosivat toiminnallista testausta. Rakennetestaus soveltuu paremmin matemaattiseen mallinnukseen, mutta tämä ei tarkoita, että se olisi tehokkaampaa. Jokaisen tekniikan avulla voit tunnistaa toista käytettäessä havaitut virheet. Tästä näkökulmasta niitä voidaan kutsua yhtä tehokkaiksi.

Testauksen kohteena ei voi olla vain ohjelman koko polku (komentosarja, jonka se suorittaa alusta loppuun), vaan myös sen yksittäiset osat. On täysin epärealistista testata kaikkia mahdollisia ohjelman suoritustapoja. Siksi testausasiantuntijat tunnistavat kaikilta mahdollisilta poluilta ne ryhmät, jotka on ehdottomasti testattava. Valinnassa he käyttävät erityisiä kriteerejä nimeltä kattavuuskriteerit (coveragecriteria), jotka määrittävät hyvin todellisen (vaikka melko suuren) määrän testejä. Näitä kriteerejä kutsutaan joskus loogiset kattavuuskriteerit, tai täydellisyyskriteerit.

3. Ohjelmistotuotteen ohjejärjestelmän kehittäminen. Käyttäjädokumentaation luominen

On suositeltavaa nimittää yksi projektin työntekijöistä dokumentaation tekniseksi toimittajaksi. Tämä työntekijä voi tehdä myös muuta työtä, mutta hänen päätehtävänään tulee olla dokumentaation analysointi, vaikka muut työntekijät myös kehittäisivät sitä.

Usein tapahtuu, että ohjelmiston luomisessa työskentelee useita ihmisiä, mutta kukaan heistä ei ole täysin vastuussa sen laadusta. Tämän seurauksena ohjelmisto ei vain hyödy siitä, että useammat ihmiset kehittävät sitä, vaan myös häviävät, koska kumpikin alitajuisesti siirtää vastuuta toisilleen ja odottaa, että hänen kollegansa tekevät tämän tai toisen osan työstä. Tämä ongelma ratkaistaan ​​nimittämällä toimittaja, joka on täysin vastuussa teknisen dokumentaation laadusta ja tarkkuudesta.

PP-apujärjestelmä on muodostettu käyttöoppaaseen kehitetyn materiaalin pohjalta. Sen muodostaa ja luo tämän työn suorittamisesta vastaava henkilö. Se voi olla joko tekninen editori tai yksi kehittäjistä yhdessä teknisen editorin kanssa.

Hyvin dokumentoidulla ohjelmistolla on seuraavat edut.

1. Helppokäyttöisyys. Jos ohjelmisto on hyvin dokumentoitu, se on paljon helpompi soveltaa. Käyttäjät oppivat sen nopeammin, tekevät vähemmän virheitä ja tekevät sen seurauksena työnsä nopeammin ja tehokkaammin.

2. Pienemmät teknisen tuen kustannukset. Kun käyttäjä ei ymmärrä, kuinka tarvitsemansa toiminnot suorittaa, hän soittaa piirilevyn valmistajan tekniseen tukipalveluun. Tällaisen palvelun ylläpitäminen on erittäin kallista. Hyvä käsikirja auttaa käyttäjiä ratkaisemaan ongelmia itse ja vähentämään tarvetta ottaa yhteyttä tekniseen tukitiimiin.

3. Korkea luotettavuus. Käsittämätön tai huolimaton dokumentaatio tekee ohjelmistosta vähemmän luotettavan, koska sen käyttäjät tekevät todennäköisemmin virheitä ja heidän on vaikea ymmärtää, mikä aiheutti ne ja miten käsitellä niiden seurauksia.

Huollon helppous. Käyttäjien virheistä johtuvien ongelmien analysointiin kuluu valtavasti rahaa ja aikaa. Uusiin ohjelmistojulkaisuihin tehdyt muutokset ovat usein vain muutoksia vanhojen toimintojen käyttöliittymään. Ne esitellään, jotta käyttäjät lopulta ymmärtävät, kuinka ohjelmistoa käytetään, ja lopettavat teknisen tuen soittamisen. Hyvä hallinta pitkälti

Eli EIS-ohjelmistokehityksen rakenteellisen lähestymistavan ydin on sen hajoamisessa (jakamisessa) automatisoituihin toimintoihin: järjestelmä on jaettu toiminnallisiin alajärjestelmiin, jotka puolestaan ​​on jaettu alitoimintoihin, ne tehtäviin ja niin edelleen. erityisiä menettelyjä. Samalla järjestelmä ylläpitää kokonaisvaltaista näkymää, jossa kaikki komponentit ovat yhteydessä toisiinsa. Kehitettäessä järjestelmää "alhaalta ylöspäin", yksittäisistä tehtävistä koko järjestelmään, eheys katoaa, ongelmia syntyy kuvattaessa yksittäisten komponenttien informaatiovuorovaikutusta.

Kaikki yleisimmät rakenteellisen lähestymistavan menetelmät perustuvat useisiin yleisiin periaatteisiin:

1. "hajota ja hallitse" -periaate;

2. Hierarkkisen järjestyksen periaate on periaate, jossa järjestelmän komponentit järjestetään hierarkkisiksi puurakenteiksi lisäämällä uusia yksityiskohtia jokaiselle tasolle.

Kahden perusperiaatteen eristäminen ei tarkoita, että muut periaatteet ovat toissijaisia, koska minkä tahansa niistä huomiotta jättäminen voi johtaa arvaamattomiin seurauksiin (mukaan lukien koko projektin epäonnistuminen). Tärkeimmät näistä periaatteista ovat:

1. Abstraktion periaate - järjestelmän oleellisten näkökohtien korostaminen ja merkityksettömän poistaminen.

2. Järjestelmän elementtien johdonmukaisuuden, pätevyyden ja johdonmukaisuuden periaate.

3. Tiedon strukturoinnin periaate - tiedon tulee olla jäsenneltyä ja hierarkkisesti järjestettyä.

Rakenteellisessa lähestymistavassa on pääasiassa kaksi työkaluryhmää, jotka kuvaavat järjestelmän toiminnallista rakennetta ja tiedon välisiä suhteita. Jokainen työkaluryhmä vastaa tietyntyyppisiä malleja (kaavioita), joista yleisimmät ovat:

· DFD (Data Flow Diagrams) - tietovuokaaviot;

· SADT (Structured Analysis and Design Technique - rakenneanalyysin ja suunnittelun metodologia) - mallit ja vastaavat toiminnalliset kaaviot: merkinnät IDEF0 (järjestelmien toiminnallinen mallintaminen), IDEF1х (tietokantojen käsitteellinen mallinnus), IDEF3х (järjestelmien rakentaminen järjestelmien laadun arvioimiseksi). objektin työn graafinen kuvaus virtausprosesseista, prosessien ja näiden prosessien muuttamien kohteiden vuorovaikutuksesta);

· ERD (Entity - Relationship Diagrams) - entiteetti-suhdekaaviot.

Lähes kaikki rakenteellisen lähestymistavan (rakenneanalyysin) menetelmät ohjelmistovaatimusten muodostusvaiheessa käyttävät kahta mallinnustyökalujen ryhmää:

1. Kaaviot, jotka kuvaavat toimintoja, jotka järjestelmän on suoritettava, ja näiden toimintojen välisiä suhteita - DFD tai SADT (IDEF0).

2. Kaaviot, jotka mallintavat tietoja ja niiden suhteita (ERD).

Listattujen kaavioiden erityinen muoto ja niiden suunnitelmien tulkinta riippuu ohjelmiston elinkaaren vaiheesta.

Ohjelmistovaatimusten muodostusvaiheessa SADT-malleja ja DFD:tä käytetään ”AS-IS”- ja ”TO-BE”-mallin rakentamiseen, mikä kuvastaa organisaation liiketoimintaprosessien olemassa olevaa ja ehdotettua rakennetta ja niiden välistä vuorovaikutusta ( SADT-mallien käyttö rajoittuu yleensä vain tähän vaiheeseen, koska niitä ei alun perin ollut tarkoitettu ohjelmistosuunnitteluun). ERD:n avulla organisaatiossa käytetyn datan kuvaus toteutetaan käsitteellisellä tasolla riippumatta tietokannan toteutustyökaluista (DBMS).

1. Ohjelmointitekniikan tarkoitus. Ohjelmointitekniikan kehityksen historia. Ohjelmistoprojektien tyypit. Ohjelmointitekniikan komponentit. Projekti, tuote, prosessi ja ihmiset

2. Ohjelman elinkaari. Kehityksen syklinen luonne. Ohjelmointitekniikan peruskäsitteet. Prosessit ja mallit. Vaiheet ja käännökset. Virstanpylväät ja esineet. Sidosryhmät ja työntekijät.

3. Vaatimusten tunnistaminen ja analysointi. Ohjelmistovaatimukset. Vaatimusten kehittämisen vuokaavio. Vaatimusten hallinta.

4. Arkkitehtoninen ja yksityiskohtainen suunnittelu. Toteutus ja koodaus. Testaus ja todentaminen. Laadunvalvontaprosessi. Valkoisen ja mustan laatikon menetelmät. Tarkastukset ja katsaukset. Tavoitteiden testaus. Varmennus, validointi ja järjestelmän testaus. Huolto ja jatkuva kehitys.

5. Kehitysprosessin mallit. Vesiputous- ja kuljetinmallit. Spiraali- ja inkrementtimallit. Joustavat kehitysprosessimallit.

6. Prosessimallin rakentaminen. Tunnista prosessivaatimukset. Käytetyt vaiheet, virstanpylväät ja artefaktit. Prosessiarkkitehtuurin valinta. Vakioprojektin toteuttamismenettely. Dokumentoidut menettelyt.

7. Kehitystiimien mallit. Kehityksen kollektiivinen luonne. Optimaalinen joukkueen koko. Hankkeen osallistujien alisteisuus. Joukkueen kehittäminen ja henkilöstön kehittäminen. Erikoistuminen, yhteistyö ja vuorovaikutus.

8. Kehitystiimien mallit. Hierarkkinen tiimimalli. Kirurginen ryhmämenetelmä. Vertaistiimin malli.

9. Ohjelmoinnin luonne. Ohjelmoinnin tiede. Ohjelmoinnin taito. Ohjelmoinnin taito. Ohjelmointiparadigmat. Strukturoitu ohjelmointi. Logiikka ohjelmointi. Olio-ohjelmointi.

10. Ohjelmistoarkkitehtuuri. Tapahtuman hallinta. Asiakas/palvelin arkkitehtuuri. Palvelut. Kolmikerroksinen arkkitehtuuri. Ohjelman suunnittelu. Käsitteellinen suunnittelu. Looginen suunnittelu. Yksityiskohtainen suunnittelu.

1. Novikov lähestyy ohjelmistokehitystä" http://window. /window_catalog/files/r60368/itmo307.pdf.

2. Äärimmäinen ohjelmointi. – Pietari: Pietari, 2002.

3. Ohjelmistokehitystekniikka. – Pietari. : Peter, 2004.

4. Brooks Jr. ohjelmistojärjestelmiä suunnitellaan ja luodaan. M.: Nauka, 1975; käännöksen uusi painos: The Mythical Man-Month. SPb.: SYMBOL+, 1999.

5. Algoritmit + tietorakenteet = ohjelmat. M., Mir, 1978.

6. Systemaattinen ohjelmointi. Johdanto. M.: Mir, 1977.

7. Strukturoitu ohjelmointi. M.: Mir, 1975.

8. Ohjelmointikuri. M.: Mir, 1978.

9. Ohjelmistokehitystekniikat. – Pietari: Pietari, 2002.

10. Terekhovin ohjelmointi. M.: BINOM, 2006.

11. Rambo J. Yhtenäinen ohjelmistokehitysprosessi. Pietari: Pietari, 2002.

Talousteoria johtajille

Mikrotalouden perusteoriat. Esimerkkejä sovelluksista taloudellisten prosessien analysoinnissa. Makrotalouden perusteoriat. Esimerkkejä sovelluksista taloudellisten prosessien analysoinnissa. Talousprosessien johtamisen periaatteet ja menetelmät. Taloudellisten prosessien kehitystason arviointityökalut Laajentuneen lisääntymisen ongelmat. Venäjän talouden talouskasvun tekijät. Kestävän kehityksen kriteerit ja indikaattorit. Tasoittaa suhdannevaihteluita. Kertojan ja kiihdyttimen rooli taloudellisen kehityksen vauhtia arvioitaessa. Taloustieteen tuotantotoiminnot. Esimerkkejä sovelluksista taloudellisten prosessien analysoinnissa. Voitto. Tulokseen vaikuttavien tunnuslukujen laskenta, kannattavuusrajan graafinen esitys. Metodologia investointipolitiikan toteuttamiseksi.

Talousteorian kurssi: oppikirja yliopistoille / Toim. . –Kirov: “ASA”, 2004. Kolemaev - matemaattinen mallinnus. Makrotaloudellisten prosessien ja järjestelmien mallintaminen: oppikirja. M.: UNITY-DANA, 2005. Bazhin-kybernetiikka. Kharkov: Consul, 2004. Leushin-työpaja matemaattisen mallintamisen menetelmistä: oppikirja. Nižni Novgorodin osavaltio tekniikka. yliopisto - N. Novorod, 2007. Taloustieteen poliitikot: taloustieteen Nobel-palkittujen luentoja. M.: Moderni taloustiede ja oikeus, 2005. Cheremnykh. Edistynyt taso: Oppikirja.-M.:INFRA-M, 2008. Pienitalousinstituutioiden kehitys. Taloustieteen instituutti, Venäjän tiedeakatemian Uralin haara, - M.: Nauka, 2007.

Tekniikat kehitystä ja johtamispäätösten tekemistä varten [N]

Päätöksenteko esimiehen toiminnan perustana. Johdatus päätöksenteoriaan. Päätösteorian peruskäsitteet. Liiketoiminnan johtamismallit ja niiden vaikutus päätöksentekoon. Erilaisia ​​tapoja luokitella ratkaisuja. Luokitukset: muodollisuusasteen mukaan, rutiininomaisuuden asteen mukaan, esiintymistiheyden mukaan, kiireellisyyden mukaan, tavoitteiden saavuttamisasteen mukaan, vaihtoehdon valintatavan mukaan. Päätöksenteon perusmenetelmät. Vapaaehtoiset päätöksentekomenetelmät. Päätöksenteon tavoitteet. Aikaa etsiä ratkaisuja. Perusvirheet Päätöksenteon matemaattiset menetelmät. Päätösteorian matemaattiset näkökohdat. Toimintatutkimus. Matemaattinen lähestymistapa päätöksentekoon. Päätöspuu. Kehityksen ja päätöksenteon mallit. Pelin teoria. Matemaattiset päätöksenteon menetelmät. Päätösteorian matemaattiset näkökohdat. Jonoteorian mallit. Varastonhallintamallit. Lineaarinen ohjelmointimalli. Kuljetustehtävät. Simulaatiomallinnus. Verkkoanalyysi. Taloudellinen analyysi. Rationaalisten mallien rajoitukset. Ryhmän kehittämisen ja päätöksenteon piirteet. Menetelmä ryhmän koheesion määrittämiseksi joukkojen liitettävyyden asteen perusteella. Menetelmät kollektiivisten päätösten tekemiseen. Konsensusmenetelmä. Äänestysmenetelmät. Luovat päätöksentekomenetelmät. Aivoriihi. Ideoiden konferenssi. Laivan neuvosto. De Bonon "Thinking Hats" -menetelmä. Keksinnöllisen ongelmanratkaisun teoria (TRIZ). Täydellinen loppuratkaisu. Esimerkkejä ongelmista ja niiden ratkaisuista TRIZ:n avulla. TRIZ-menetelmien soveltaminen tehtäessä ainutlaatuisia ja luovia päätöksiä. Menetelmiä ratkaisuideoiden kehittämiseen ja sopeuttamiseen tilanteeseen. Tavoitepuu malli. Strategia etujen yhteensovittamiseksi. Päätösten tekeminen etujen yhteensovittamiseksi. Menetelmät vastapuolten intressien määrittämiseksi. Päätöksen tukijärjestelmät (asiantuntijajärjestelmät). Päätöksentekojärjestelmien luomisen historia. Päätöksentekojärjestelmien luokittelu. Tyypillinen asiantuntijajärjestelmän rakenne. Tiedon esittämisen menetelmät. Loogisen päättelyn menetelmät. Asiantuntijajärjestelmien soveltaminen käytännössä.

I. Päätöksenteon teoria: Oppikirja. - M.: Tentti, 2006. - 573 s. I. Päätöksenteko. Teoria ja menetelmät johtamispäätösten kehittämiseen. Opinto-opas. - M.: MarT, 2005. - 496 s. Johdon päätösten kehitys - M.: Kustantaja "Delo", 2004 - 392 s. G. Asiantuntijaarviot ja päätöksenteko - M.: Patentti, 1996. - 271 s. Taha // Johdatus operaatiotutkimukseen = Operations Research: An Introduction. - 7. painos - M.: "Williams", 2007. - S. 549-594. G. Theil. Talousennusteet ja päätöksenteko. M.: "Progress" 1970. K. D. Lewis. Talousindikaattoreiden ennustamismenetelmät. M.: "Rahoitus ja tilastot" 1986. G. S. Kildishev, A. A. Frenkel. Aikasarjaanalyysi ja ennustaminen. M.: “Statistics” 1973. O. Kim, C. W. Muller, U. R. Klekka ja muut tekijät, diskriminantti- ja klusterianalyysi. M.: "Rahoitus ja tilastot" 1989. Tehokas johtaja. Kirja 3. Päätöksenteko. – MIM LINK, 1999 Turevsky ja moottorikuljetusyrityksen johto. - M.: Higher School, 2005. , ; muokannut . Järjestelmäanalyysi johtamisessa: oppikirja. – M.: Talous ja tilastot, 2006. , Tinkov: oppikirja. – M.: KNORUS, 2006.

Liiketoimintaprosessien mallintaminen integroiduissa johtamisjärjestelmissä

Millä periaatteilla liiketoimintaprosessit erotetaan? Mikä on liiketoimintaprosessien kokonaisvaltaisen kuvauksen ongelma? Mikä on järjestelmä, mitä ominaisuuksia sillä on? Järjestelmäanalyysin rooli liiketoimintaprosessien mallintamisessa? Prosessi hallinnan kohteena. Prosessiympäristö. Liiketoimintaprosessin peruselementit. Toiminnallisen ja prosessihallinnan edut ja haitat. PDCA-hallintasykli. Prosessinhallintasyklin vaiheet. PDCA-sykli ja ISO 9001:2008 vaatimusten toteutus. SADT-metodologia (Structured Analysis and Design Technique - menetelmä rakenneanalyysin ja suunnittelun). Essence. Perussäännökset. Miten toiminnallinen toimintamalli esitetään IDEF0-metodologiassa? Mitä toimintamallikaavioiden toiminnot tarkoittavat, miten ne esitetään IDEF0-metodologian mukaan? Mitä nuolet toiminnallisten mallien kaavioissa tarkoittavat, mitkä ovat niiden tyypit ja tyypit? DFD-metodologia. Essence. DFD-kaavioiden peruskomponentit. Mitä ominaisuuksia DFD-kaavioilla on ja mitä niissä kuvataan? Mitkä ovat DFD-kaavioobjektien ominaisuudet? Mitä nuolet DFD-kaaviossa tarkoittavat? IDEF3-metodologia. Essence. Dokumentointi ja mallinnustyökalut. Mitä ominaisuuksia IDEF3-kaavioilla on ja mitä niissä kuvataan? Mitkä ovat IDEF3-kaavioobjektien ominaisuudet? Ja ampuja? Prosessien luokittelu. Tyypillisiä liiketoimintaprosesseja. Uudelleensuunnittelu ja sen tekniikka. Milloin uudelleensuunnittelua kannattaa käyttää yrityksen johtamisessa? Valvonta- ja mittausprosessit. Organisaatioprosessien indikaattorit. Prosessien numeeriset ja luokitusarvioinnit.

"Liiketoimintaprosessien mallinnus AllFusion Process Modelerillä (BPwin 4.1) Dialog-MEPhI" 2003 "Tietojärjestelmien luominen AllFusion Modeling Suitella" toim. "Dialogue-MEPhI" 2003 "Toimintamallinnuksen harjoittelu AllFusion Process Modeler 4.1:llä. (BPwin) Missä? Miksi? Miten?" toim. "Dialogue-MEPhI" 2004 Dubeykovskin mallinnus AllFusion Process Modelerillä (BPwin). toim. "Dialogue-MEPhI" 2007 D. Mark, K. McGowan "Rakenneanalyysin ja suunnittelun metodologia SADT" 1993 klassinen työ SADT-metodologiasta. Cheremnykh-järjestelmäanalyysi: IDEF-teknologiat, Järjestelmän mallinnus ja analyysi. IDEF-teknologiat. Työpaja. M.: Finance and Statistics, 2001. "Rakenteelliset liiketoimintamallit: DFD-teknologiat" http://www. /Level4.asp? ItemId=5810 "Liikeprosessien uudelleenorganisoinnin teoria ja käytäntö" 2003/ P50.1.. Toiminnallisen mallinnuksen metodologia. M.: Gosstandart of Russia, 2000. http://www. IDEF0, IDEF3, DFD http://www. Liiketoimintaprosessien mallintaminen BPwinillä http://www. /department/se/devis/7/ IDEF0 liikkeenjohdon prosessien mallintamisessa http:///content/view/21/27/ http://www. /dir/cat32/subj45/file1411/view1411.html http://www. http://www.

Ohjelmistotuotteiden tehokkuuden arviointi

1. IT-arkkitehtuuri

2. Hallintoprosessien alueet.

3. Luettelo suunnittelu ja organisaatio -alueen prosesseista

4. Luettelo toimialueen prosesseista hankinta ja toteutus

5. Luettelo käyttö- ja ylläpitoalueen prosesseista

6. Luettelo seuranta- ja arviointialueen prosesseista

7. Prosessin kypsyysmallin tasojen ominaisuudet

9. KPI ja KGI heidän suhteensa ja tarkoituksensa

1. 10.Yleiset IT-ohjaimet ja sovellusten hallintalaitteet. Liiketoiminnan ja IT:n vastuualueet ja vastuualueet.

Cobit 4.1 venäläinen versio.

Immateriaaliomaisuuden luomisen ja käytön oikeudellinen sääntely

1. Listaa henkisen toiminnan tulosten immateriaalioikeudet ja paljasta niiden sisältö.

2. Luettelo yksinoikeuksien luovuttamista koskevien sopimusten tyypit. Kuvaa jokainen näistä yksinoikeuksien luovuttamista koskevista sopimuksista.

4. Kuvaile tietokoneohjelman tekijänoikeuden kohteena olevan oikeussuojan pääsäännöt.

5. Vertaa tietokannan oikeussuojaa koskevia keskeisiä säännöksiä tekijänoikeuden kohteena ja lähioikeuksien kohteena.

6. Kuvaa patentoitavuuden edellytykset patenttioikeuden kohteille: keksinnöt; hyödyllisyysmallit; teolliset mallit.

7. Laajenna keksinnön patentoitavuuskriteerien sisältöä: uutuus; kekseliäs askel; teollinen soveltuvuus.

8. Kuvaa keksinnön, hyödyllisyysmallin tai teollisen mallin patentin saamisen ehdot ja menettely sekä patenttien voimassaolon varmistavat ehdot ja niiden voimassaoloajat.

9. Määrittele ”taitotieto” ja luettele olosuhteet, joiden luomisen yhteydessä syntyy ja toteutetaan tuotantosalaisuuksien oikeudellinen suoja.

10. Luettele suojatut yksilöllistymiskeinot ja anna niiden vertailuominaisuudet.

1., Immateriaalioikeudet Venäjän federaatiossa, oppikirja // M, Prospekt, 2007.

2., Immateriaalioikeus, oppikirja // M, RIOR, 2009.

Projektien ja ohjelmistokehityksen hallinta [I]

Mikä on metodologia, miksi sitä tarvitaan. Metodologian yleinen rakenne, metodologian pääelementit. Periaatteet oman metodologian suunnitteluun. Esimerkkejä erilaisista esineistä, rooleista, kompetensseista ja rajaehdoista. Metodologian rakenne Cowburnin mukaan, metodologian metriikka. Cowburnin suunnittelukriteerit. Metodologian valintakriteerit, Cowburn-matriisi. Projektin elinkaari. Vesiputous ja iteratiiviset elinkaarimallit. Vesiputouksen ja iteratiivisten mallien sovellettavuusrajat. RUP esimerkkinä iteratiivisesta metodologiasta. RUP:n peruskäsitteet, sovellettavuuden rajat. Ihmisen rooli ohjelmistokehityksessä. Ketterät metodologiat, ketterän metodologian perusperiaatteet. Syy joustavien menetelmien syntymiseen. Scrum esimerkkinä joustavasta menetelmästä. Roolit, esineet, aktiviteetit Scrumissa. Scrum-käytettävyysrajat. Extreme Programming (XP) Ideat, arvot, peruskäytännöt, sovellettavuusrajat. Scrumin ja XP:n yhtäläisyydet ja erot. Vaatimusten kerääminen ja hallinta. Peruskäytännöt, termit, periaatteet. Lähestymistavat projektin ja tuotteen dokumentointiin, pääasialliset asiakirjatyypit. Esimerkkejä vaatimustenhallinnan käytännöistä kurssilla käsitellyistä metodologioista. Ohjelmistokehityssuunnittelu. Suunnitelmatyypit, riskienhallinta, suositut riskit. Esimerkkejä kehittämisen suunnittelun käytännöistä kurssilla käsitellyistä metodologioista. Testaus ohjelmistokehityksessä. Ohjelmistotuotteen kokoamisen (build) käsite. Perustestausmenetelmät, termit. Esimerkkejä testauskäytännöistä kurssilla käsitellyistä menetelmistä. Kokoonpanon (build) käsite, koodin tallennusmenetelmät, työkalut. Kaksi periaatetta työn organisoimiseksi versionhallintajärjestelmän kanssa. Tuotteiden julkaisu/näyttöprosessin ominaisuudet eri tuoteryhmille, esimerkkejä käytännöistä. Nykyaikaiset ohjelmistoarkkitehtuurin käsitteet, monitasoiset arkkitehtuurit, arkkitehtuurin kriteerit. Luettelo tarvittavista päätöksistä ohjelmistojen suunnittelussa, lähestymistapoja tiedontallennusjärjestelmän valintaan.

Kent Beck - Extreme Programming Frederick Brooks - Myyttinen mieskuukausi eli kuinka ohjelmistojärjestelmiä luodaan. Tom DeMarco - Määräaika. Romaani projektinhallinnasta. Tom De Marco, Timothy Lister - Valssi karhujen kanssa. Tom de Marco, Timothy Lister - Inhimillinen tekijä - onnistuneet projektit ja tiimit. Alistair Cowburn - Jokaisella projektilla on oma menetelmänsä. Alistair Cowburn - Ihmiset epälineaarisina ja tärkeimpinä komponentteina ohjelmistojen luomisessa. Andriy Orlov - Automaatioinsinöörin muistiinpanot. Ammattimainen tunnustus. Philipp Kratchen - Johdatus Rational Unified Prosessiin. Henrik Kniberg - Scrum ja XP: muistiinpanoja etulinjoilta. Kurssin luentojen esitykset