80/20 vaikuttaa myös ajoitukseen

Olemme kaikki kuulleet 80/20-säännöstä, joka sanoo, että 80% menestyksestämme (vaikutuksistamme) tulee vain 20%: sta toiminnastamme (syistä). No, tämä yleismaailmallinen totuus vaikuttaa myös ohjelmistokehitykseen, ja tässä artikkelissa kerromme hieman tämän lausunnon perusteista.

BPM

Liiketoimintaprosessien hallinta on lyhenne englanniksi lyhytketjuinen johtamisala (muun muassa), jonka avulla voit visuaalisesti ymmärtää prosessit, jotka on suoritettava yrityksessä (tai monissa muissa paikoissa). Yksi sen pääominaisuuksista on se, että se voi analysoida monimutkaisia ​​prosesseja ja tehdä niistä "yksinkertaisia".

On olemassa monia avoimen lähdekoodin työkaluja, joiden avulla voit kehittää BPM-kaavioita, jota olen käyttänyt tässä artikkelissa, on BonitaSoft. Jos haluat oppia lisää prosessinhallinnasta, Internetissä on monia oppaita ja kirjoja aiheesta. Palataan nyt keskeiseen aiheeseen.

Ohjelmistoprojektit

Nykyään projektien kehittämiseen on monia menetelmiä: ketteriä, perinteisiä, hybridi- ja niin edelleen. Yksi asia yhdistää niitä kaikkia: valmistautuminen . Mitä tarkoitan tällä? Että 80 % menestyksestäsi tässä ohjelmistoprojektissa riippuu koko prosessin ensimmäisestä 20 prosentista: valmistautumisesta.

Projektin valmistelu

Tämä on looginen näkökohta, jota harvoin sovelletaan todellisuudessa (kuten monia muita loogisia asioita, jotka ovat käytännössä epäloogisia). Kun puhumme valmistautumisesta, meidän on ymmärrettävä kyky ymmärtää ongelma, ymmärtää ratkaisu ja ennen kaikkea ratkaisun käyttämä prosessi . Yksi harvinaisimmista asioista, joita epäammattimaisissa ohjelmistoprojekteissa esiintyy, on aiheen dokumentaation puute. Tämä tapahtuu yleensä yksityisissä yrityksissä, koska myyntihalu usein varjostaa kehitysprosessia.

Koska monet näitä artikkeleita lukevista työskentelevät teknologia-alalla tai ovat siihen liittyviä, on syytä mainita, että jos he työuransa aikana kohtaavat yrityksen/toimittajan, joka ei täytä hyviä valmistautumisvaatimuksia, on lähes 80 %:n varmuudella, että projekti ei mene hyvin.

Abstraktio on avain

Tämän olen oppinut GNU/Linuxia käyttäessäni, ja se osoittautuu kerta toisensa jälkeen avainasemassa ohjelmistokehitysprosessissa. Kyky abstraktoida ongelmia ja muuttaa ne yksinkertaisemmiksi asioiksi on elintärkeää tyylikkään ja ennen kaikkea kestävän koodin luomiseksi . Ja ehkä tämä on yksi tärkeimmistä eroista suurten ammattimaisten projektien ja hallitsemattomasti kasvavien projektien välillä. Ensimmäiset ajattelevat, ymmärtävät ja jäsentävät prosessin, kun taas jälkimmäiset yksinkertaisesti pitävät sen käynnissä ilman, että niiden tarvitsee ymmärtää sitä.

näyttäjä

Tämä on projektin nimi, jonka Gentoo-asennusohjelma kehittää, kuten voitte kuvitella, tämä on melko monimutkainen prosessi, koska se tukee useita arkkitehtuureja. Toinen huomioon otettava tekijä on sen tukemien kokoonpanojen lukumäärä ytimen tasolla, init-järjestelmässä jne. Ja minä kerron tämän kaiken, koska se on myös opinnäytetyöni, joka minun on saatava päätökseen ennen opintojen lopettamista. Ilmeisesti en voi tehdä ohjelmaa, joka sisältää ehdottomasti kaikki mahdolliset vaihtoehdot niin lyhyessä ajassa (ensi vuoden heinäkuuhun asti), mutta ainakin pystyn luomaan sellaisen, joka sallii toiminnallisen järjestelmän asentamisen hyvin perustavalla tavalla.

Asennusprosessin ymmärtäminen

BPM-työkalujen ansiosta voidaan luoda prosessikaavio, jonka avulla voimme ymmärtää Gentoon onnistuneen asentamisen tietokoneeseen tarvittavat vaiheet.

Huolimatta siitä, että se sisältää useita prosesseja ja aliprosesseja, se on tietysti melko tiivistetty, ja voidaan nähdä, että meillä on 18 lineaarista vaihetta. Tämä on tärkeää, koska lineaarisen rakenteen omaava sovellus on helppo toteuttaa, ja samanaikaisesti rinnakkaisuus voidaan luoda yhdessä tai useammassa säikeessä tarvittaessa.

Toinen tärkeä tekijä on, että se antaa meille mahdollisuuden abstraktoida prosessijoukkoja tyypin mukaan; esimerkiksi ytimen aliprosessin määritteleminen antaa meille tiedon siitä, että siinä on tiettyjä tehtäviä, jotka liittyvät suoraan ytimen onnistuneen asennuksen prosessiin.

Tällä tavalla jokaisesta "monimutkaisesta" vaiheesta tulee "yksinkertainen" globaalisti menettämättä tarvittavia yksityiskohtia. Tämä helpottaa kokoonpanon näkyvyyttä heikentämättä prosessin onnistuneeseen loppuun saattamiseen tarvittavaa spesifikaatiotasoa. Emmekä voi kiistää, että on helpompi nähdä kuva kuin lukea koko käsikirja kerralla 

Säästää aikaa

Toinen ilmeinen etu on, että koska ei ole suoraan kytkettyä ohjelmointikieliä, on mahdollista suorittaa logiikka-analyysi tuhlaamatta välttämättä aikaa kielen toteuttamiseen. Tämä on etu verrattuna siihen aikaan, joka voidaan käyttää ominaisuuden toteuttamiseen vain sen selvittämiseksi, että se hylätään, koska on olemassa tehokkaampi ratkaisu. Kuten mitä pseudokoodin ratkaisut olisivat (jotain, jota myös monet "kehittäjät" jättävät huomiotta, mutta ei pidä olla).

Projektien ohjaaminen on helppoa

Nämä käsitteet huomioon ottaen projektinhallinta (kaikenlainen tahansa) yksinkertaistuu, koska keskitämme ponnistelut sinne, missä niitä todella tarvitaan, ja jos tämä osa tehdään oikein, loput jäävät oman painonsa alle. Toivottavasti se auttaa uteliaisuuttasi ja motivoi sinua tutkimaan BPM:ää, algoritmeja ja kenties se rohkaisee sinua auttamaan minua opinnäytetyössäni  Paljon kiitoksia, että olet päässyt näin pitkälle ja nähdään pian. Tervehdys