Kas ietekmē programmatūras izstrādes izmaksas

Kāds jautā, cik maksās pielāgotas programmatūras projekts, un godīga pirmā atbilde ir pretjautājums: ko tieši tai jādara? Izmaksas seko apjomam, bet apjomu nosaka dažas lietas, ko var nosaukt jau ilgi pirms jebkuras tāmes.

Īsumā#

Pielāgotas programmatūras projekta izmaksas seko tā apjomam, bet apjomu nosaka dažas lietas, kas zināmas jau ilgi pirms tāmes: cik sistēmu programmatūra skar, cik labas ir šo sistēmu saskarnes, cik lielu dīkstāvi vai datu zudumu uzņēmums var paciest, kādi noteikumi jāievēro, cik skaidras ir prasības, cik daudz tiek testēts automātiski un kas sistēmu uztur pēc palaišanas.

Summas šeit nav minētas, jo tās ir atkarīgas no šiem faktoriem un ātri noveco. Lai iegūtu noderīgu tāmi, aprakstiet problēmu, nevis risinājumu, uzskaitiet iesaistītās sistēmas, pasakiet, kas notiek, ja tās nedarbojas stundu un diennakti, un pieprasiet tāmes pieņēmumus un diapazonu ar nosauktu galveno nenoteiktību. Ja kāda no šīm lietām vēl nav skaidra, noskaidrojiet to pirms tāmes pieprasīšanas, citādi tāme balstīsies uz minējumiem.

Kas ietekmē izmaksas#

• Cik sistēmu tā skar. Atsevišķa lietotne ir viens darbs. Lietotne, kurai jālasa un jāraksta dati ERP, interneta veikalā un maksājumu pakalpojumā, ir vairāki darbi, katram ar saviem noteikumiem un saviem veidiem, kā tas var sabojāties.
• Cik labas ir citu sistēmu saskarnes. Dokumentētu, modernu API izmantot ir ātri. Sistēma, kas piedāvā tikai failu eksportu vai tiešu piekļuvi datubāzei ar savienojumu ierobežojumiem, prasa vairāk darba, lai datus nolasītu droši.
• Cik lielu dīkstāvi vai datu zudumu uzņēmums var paciest. Jo mazāk, jo vairāk jāprojektē: rindas un atkārtoti mēģinājumi, abu pušu datu salīdzināšana, uzraudzība un ieviešana, kas neaptur darbu.
• Noteikumi un regulējums. Darbību žurnāli, piekļuves kontrole, personas datu apstrāde saskaņā ar VDAR un nozares prasības, piemēram, NIS2, ja tās attiecas, prasa papildu projektēšanu un testēšanu.
• Cik skaidras ir prasības. Neskaidras vai mainīgas prasības ir biežākais iemesls, kāpēc agrīna tāme izrādās nepareiza: tas, kas tiek novērtēts, vēl nav tas, ko veiks.
• Testēšana un piegādes automatizācija. Automātiskie testi un atkārtojams deploy process sākumā prasa pūles, bet padara katru vēlāku izmaiņu lētāku un drošāku.
• Kas uztur sistēmu pēc palaišanas. Drošības atjauninājumi, labojumi un nelielas izmaiņas turpinās arī pēc palaišanas, un programmatūra bez atbildīgā noveco.

Kas veic darbu#

Projektam parasti vajadzīgi trīs darba veidi: kāds, kas projektē arhitektūru un pārskata drošību un katru posmu; inženieri, kas veido pamatfunkcijas un integrācijas; un inženieri, kas veic skaidri definētas funkcijas un testus citu uzraudzībā. Šis sastāvs ietekmē gan izmaksas, gan ātrumu, un komanda, kas riskantajām daļām ir par nepieredzējušu, to bieži vien atpērk ar pārstrādi.

Fiksēta cena vai laika un materiālu līgums#

Fiksēta cena der, ja apjoms ir labi definēts un maz ticams, ka mainīsies. Laika un materiālu līgums der, ja apjoms vēl tiek noskaidrots. Abi var nogāzties: pirmais, ja apjoms ir neskaidrs, bet cena noteikta tā, it kā tas būtu skaidrs; otrais, ja neviens neseko budžetam. Jautājiet, kāds modelis tiek piedāvāts un kas notiek, ja apjoms mainās.

Kā iegūt noderīgu tāmi#

1. Aprakstiet problēmu un to, kam tā ir, nevis risinājumu, ko jau esat iedomājies.
2. Uzskaitiet sistēmas, ar kurām programmatūrai jāsavienojas, un to, ko katra piedāvā: API, failu eksportu vai piekļuvi datubāzei.
3. Pasakiet, kas notiek, ja tā nedarbojas stundu un ja nedarbojas diennakti.
4. Pasakiet, kas jau ir: dati, dizaini, iepriekšējs mēģinājums.
5. Pieprasiet tāmes pieņēmumus un diapazonu ar nosauktu galveno nenoteiktību, nevis vienu skaitli.

Ko šis raksts neaptver#

Raksts nesniedz summas, jo tās ir atkarīgas no apjoma un ātri noveco. Tas nav juridisks padoms; ja runa ir par regulētiem datiem, prasības apstipriniet ar speciālistu.

Nevo izstrādā pielāgotu programmatūru un integrācijas. Ja plānojat projektu, skatiet programmatūras izstrāde.