Tässä artikkelissa yritämme kertoa ja näyttää (joitakin myyttejä rikkoen), kuinka se arvioidaan ja mitkä ovat mukautetun järjestelmän kustannukset. Ennen kuin alamme selittää erilaisia tapoja arvioida vaivaa, meidän on ensin määriteltävä, mikä arvio on.
Mikä on ohjelmistoarvio?
Ohjelmistoarvio on ennuste siitä, kuinka kauan ohjelmistoprojektin kehittäminen ja ylläpito kestää ja kuinka paljon se maksaa.Räätälöity ohjelmistokehitys.
- Aika-arvio:Työ voidaan ilmaista tunteina/henkilö.
- Kustannusarvio:Se voidaan ilmaista valitsemassasi valuutassa.
Suurin haaste arviota tehtäessä on tehdärealistisia ennusteita, perustuu epätäydellisiin ja epävarmoihin tietoihin. Tämä ei ole helppo tehtävä, koska jos sinulla ei ole riittävää kokemusta, virhemarginaalit voivat olla suuria ja seuraukset eivät ole kovin suotuisia.
Ohjelmistoarvio: mukautetun järjestelmän hinta
Tunnista tavoitteet ja sitoumukset
Räätälöidyssä järjestelmäprojektissa tavoitteiden ja lupausten (sitoumusten) asettaminen on avaintekijä, koska tärkeintä ei ole ennustaa tulosta, vaanSelvitä, ovatko asiakkaasi liiketoimintatavoitteet realistisia ja saavutettavissa.
Kun tiedät alusta alkaen saavutettavan tavoitteen ja tehdyt sitoumukset, voit määrittää, onko mukautettu järjestelmä valmis tiettyyn päivämäärään mennessä.
Tunne projektin toiminnallinen laajuus
Yksi tärkeimmistä asioista tiedossamikä on mukautetun järjestelmän hintaSe on ymmärtämistä, mitä haluat kehittää ja mitä laajuutta sillä on.
Joissakin tilanteissa on olemassa yksityiskohtaista tietoa ja dokumentaatiota, jonka avulla voimme ymmärtää laajuuden ja sen, mitä järjestelmän tekeminen edellyttää. Useimmissa tapauksissa näin ei kuitenkaan tapahdu, ja silloin prosessista tulee monimutkaisempi ja epävarma. Näissä tapauksissa se on määriteltävä.
Määritä toiminnallinen laajuus
On tärkeää aloittaa sen määrittäminen erilaisten tapaamisten ja keskustelujen kautta asiakkaan kanssa, miettiä liiketoiminnan kaupallista tarvetta ja erilaisia sitoumuksia. Tämän saavuttamiseksi on suositeltavaa suorittaa seuraavat toimet:
- Koordinoi kokouksiasaadakseen paremman ymmärryksen yrityksestä. Jos on tarpeen suorittaa kysely ja analyysi henkilökohtaisesti;
- Tutki samanlaisia järjestelmiäjoka voi toimia viitteenä;
- Ymmärrä toimialajohon asiakas kuuluu ja projektin tyyppi;
- Vahvista ja priorisoiluodut toiminnalliset vaatimukset.
Määritä EI-toiminnalliset vaatimukset
Toisin kuin toiminnalliset vaatimukset, jotka kuvaavat "mitä järjestelmän pitäisi tehdä", on tärkeää ottaa huomioonei-toiminnalliset vaatimuksetjotka kuvaavat "miten" järjestelmän pitäisi toimia, koska ne vaihtelevat suuresti määritettäessä mukautetun ohjelmiston kustannuksia.
Esimerkiksi hyvin yleinen toiminnallinen vaatimus voi olla "Näytä kaikki ladatut asiakkaat ruudukossa". Ei-toiminnallinen vaatimus, jonka voimme määrittää tästä, olisi: "Järjestelmän on vastattava alle 3 sekunnin viiveellä."
EI-toiminnalliset vaatimukset
- Skaalautuvuus
- Esitys
- Korkea saatavuus
- Turvallisuus
- Käytettävyys
- Yhteentoimivuus
- Huolto
Kunkin ei-toiminnallisen vaatimuksen tärkeys riippuu projektityypistä ja toimialasta, johon yritys kuuluu. Lisäksi on tärkeää selventää, että hankkeen kontekstista riippuen niiden toteuttamisen monimutkaisuus voi vaihdella.
Määrittele prioriteetit
Usein projektien arviot ja rajoitukset (budjetti, aika, resurssit jne.) voivat vaikeuttaa asetettujen tavoitteiden saavuttamista.
Tällaisissa tilanteissa se on tärkeäätietää ja ottaa huomioon tärkeimmät prioriteetitjotta resurssit voidaan keskittää tehokkaammin ja siten pystyä täyttämään kriittisimmät vaatimukset ensin.
Mikäli pahin mahdollinen skenaario toteutuu, vähemmän kriittiset vaatimukset siirtyisivät hankkeen toiseen vaiheeseen. On tärkeää ottaa huomioon yrityksen budjetti ja se, mikä olisi järjestelmän hinta silloin.
Tärkeä avain!Kohdista suunnitelmat arvioiden, tavoitteiden ja sitoumusten kanssa.
Hankesuunnittelu
Arviot ovat suunnittelun perusta, koska niiden avulla voit määrittää, onko sinuntavoitteet saavutettavissa vai ei. Jos ne eivät ole, suunnitelmissa on tunnistettava ero ja otettava huomioon hankkeen suuret riskit.
Toisaalta, jos tavoitteet ovat saavutettavissa eikä niiden ja arvioiden välillä ole eroa, niin suunnitelmatottaa pienen riskinja se esitetään kaaviona tämän käsitteen alla.
Seuraavassa on esimerkkejä arvioista riippuvista huomioista, jotka on otettava huomioon suunnittelun aikana:
- Tunnista projektin kriittinen polku;
- Luo täydellinen työn erittelyrakenne (lataus- ja asiakirjavaatimukset);
- Priorisoi toimitukset;
- Jaa projekti iteraatioihin.
Strategiat mukautetun järjestelmän kustannusten arvioimiseksi
Kun on analysoitu projektin tyyppi, sen monimutkaisuus, hankittu ja kerätty tieto, vaatimusten määrä (toiminnallinen ja ei-toiminnallinen) ja arvion toimitusaika, on aika valita oikea strategia.
Perinteinen ohjelmistoarviointi
Se koostuu tarpeen arvioimisesta jamääritä kiinteä arvioitu aika-arvo, joka riippuu havaitun monimutkaisuuden tasosta ja harkittavan ammattilaisen kokemuksesta.
Tarkkuuden lisäämiseksi yleensä tehdäänjakaa vaatimus komponentteihin(käyttöliittymä, yritys, tietokanta jne.)ja määritä aika jokaiselle. Tällöin kunkin komponentin estimaattien summa on vaatimuksen kokonaisestimaatti.
Tämä strategia, vaikka se onkin tarkin, ei olisi sopivin, jos vaatimuksia on paljon tai jos arvioidut toimitusajat ovat lyhyitä.
Arviointi monimutkaisuusjärjestyksessä
Tämä arviointistrategia mukautetun järjestelmän kustannusten laskemiseksi koostuumäärittää monimutkaisuuden jokaiselle vaatimukselle. Tämä mitataan yleensä tarinapisteinä: 1,2,3,5,8,13.
Tarvemäärä "x" poimitaan ja arvioidaan perinteisesti. Arvioiden keskiarvo lasketaan monimutkaisuuden mukaan, eli jos on olemassa kolme kompleksisuuden 2 vaatimusta, jotka arvioitiin, niistä lasketaan keskiarvo.
Lopuksi otetaan huomioon arvioimattomat vaatimukset ja niille annetaan arvioitu arvo monimutkaisuudesta.
Arvio analogisesti
Se koostuu kokemuksen käsitteeseen perustuvasta arvioinnista. Yrityksen aikaisemmissa projekteissa saavuttamat todelliset ajat kertovat parhaiten, kuinka kauan samanpituinen projekti voi kestää.
Tällaisten arvioiden saavuttamiseksi tietyt vaatimukset on täytettävä:
- Sinulla on laaja kokemus;
- Seuraa aikaisempien projektien aikoja (mitä enemmän, sen parempi);
- Ylläpidä arkistoa vastaavien projektien havaitsemiseksi.
Arvio joukkueittain
Se koostuu vaatimusten jakamisesta komponentteihin tai moduuleihin erikoistumisen mukaan. Tällä tavalla nämä moduulit voidaan toimittaa erikoistuneiden ammattilaisten tiimille, joka on omistautunut arvioimaan niitä.
Jokainen ryhmä arvioi määritetyt vaatimukset käyttämällä mitä tahansa aiemmin selitetyistä strategioista.
Tätä strategiaa suositellaan, kun arvioitavia vaatimuksia on suuri määrä.
Rekisteröi oletukset
Arviointiin liittyy yleensä paljon epävarmuutta lähinnä siksi, että asiakkaat eivät tiedä haluamansa/tarvitsemansa tuotetta. Tässä tulee analyytikon kokemus ja taito pystyä pitämään kokouksia ja konsultaatioita määrittämäänmitä asiakas todella tarvitsee.
Usein kaikkia epäilyksiä ei kuitenkaan yksinkertaisesti ole mahdollista ratkaista. Siksi on erittäin tärkeää kirjata kaikki oletukset, jotka voivat vaikuttaa projektin arviointiin ja suunnitteluun.
Tämä on erittäin käytännöllinen ja keskeinen tapa analysoitaessa ja arvioitaessa projekteja mukautetun järjestelmän kustannusten määrittämiseksi, koska se vähentää kaikenlaisten väärinkäsitysten riskiä (joka voi johtaa toiminnallisuuden virheelliseen kehittämiseen), jotka johtuvat epäselvyyksistä tai puutteellisuuksista. tiedot.
Kustannusarvio
Jotkut muuttujat, jotka sisältyvät mukautetun ohjelmiston hintaan, ovat:
- työvoima;
- laitteistot ja ohjelmistot (lisenssit);
- toimistokulut;
- koulutukset;
- sovellettava menetelmä.
Se sanoi, mitä yleensä tehdään, erityisesti yrityksissä, jotka tarjoavatSaaS(Software as a Service) kokoaa ja myy laitteita, joissa jokaiselle resurssille on määritetty rahallinen hinta. Tämän ansiosta yritys voi tarjota kuukausittaisen tiimityöskentelytavan.
Tämän työskentelytavan edut ovat valtavat:
- Asiakkaalla on enemmän hallintaa laitteistoon, koska se kasvattaa tai pienentää sen kokoa senhetkisen tarpeen mukaan.
- Henkilökohtaisempaa palvelua tarjotaan, koska sen tavoitteena on, että asiakas ja tiimi ovat jatkuvassa yhteydessä.
- Tuotteen korkeampi laatu varmistetaan. Tämä johtuu myös asiakkaan ja tiimin välisestä tiiviistä yhteydenpidosta, koska sen avulla voit havaita virheet tai väärinkäsitykset etukäteen.
- Viiveen sattuessa se havaitaan välittömästi ja antaa sinun ilmoittaa ja hallita odotuksia tehokkaammin.
Johtopäätös
Räätälöityjen ohjelmistoprojektien arvioiminen ei ole helppo tehtävä. On suositeltavaa, että sinulla on ammattilaisten tiimi, jolla on laaja kokemus ohjelmistokehityksestä ja jotka ovat olleet yhteydessä mahdollisimman moniin toimialoihin, jotta ne pystyvät kattamaan ja arvioimaan räätälöidyn järjestelmän kustannukset kaikenlaiseen liiketoimintaan.
Tärkeintä arvioinnissa on pystyä ymmärtämään selkeästi laajuus, tavoitteet ja sitoumukset (lupaukset) ja käyttää tässä artikkelissa lueteltuja suosituksia tavoitteenaan vähentää mahdollisimman paljon epävarmuustekijöitä ja saada tarkka arvio. sekä ajallisesti että kustannuksiltaan.
Germán Stark, ohjelmistokonsultti ja -kehittäjä.
