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 on monia menetelmiä projektien kehittämiseen, on ketteriä, perinteisiä, sekoitettuja jne., Jne. Yksi asia, joka heillä kaikilla on yhteistä, on valmistelu. Mitä tarkoitan tällä? Tämä 80% menestyksestäsi tässä ohjelmistoprojektissa perustuu koko prosessin ensimmäisiin 20 prosenttiin, valmistelu.
Projektin valmistelu
Tämä on jotain loogista, jota todellisuudessa käytetään hyvin vähän (kuten monia muita käytännössä epäloogisia asioita). Kun puhumme valmistautumisesta, meidän on ymmärrettävä kyky ymmärtää ongelma, ymmärtää ratkaisu ja ennen kaikkea prosessi että ratkaisu pätee. Yksi epäammattimaisissa ohjelmistoprojekteissa esiintyvistä asioista on asiaa koskevien asiakirjojen puute. Tämä näkyy yleensä yksityisissä yrityksissä, koska halu myydä ylittää luomisprosessin.
Koska monet artikkeleita lukevista työskentelevät tai liittyvät tekniikkaan, on syytä mainita, että jos he jossakin työelämän vaiheessa löytävät yrityksen / toimittajan, joka ei täytä hyvää valmistelua, on melkein 80% varma 😛 projekti se ei toimi.
Abstraktio on avain
Tämän olen oppinut aikani GNU / Linuxin käytöstä, ja se osoittautuu kerta toisensa jälkeen avainasemassa ohjelmistojen luomisprosessissa. Kapasiteetti abstrakti ongelmat niiden muuttamiseksi "yksinkertaisemmiksi" asioiksi on elintärkeää, jotta pystytään luomaan tyylikäs koodi ja ennen kaikkea kestävä. Ja ehkä tämä on yksi suurten ammatillisten projektien ja hallinnan ulkopuolelle kasvavien projektien tärkeimmistä eroista. Ensimmäiset ajattelevat, ymmärtävät ja rakentavat prosessi kun sekunnit he pitävät työskentelemättä tarvitsematta 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.
Oma. Christopher Diaz Riveros
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 abstrakti joukko prosesseja tyypin mukaan, esimerkiksi määrittelemällä ytimen ketju antaa meille tietää, että siinä on tiettyjä tehtäviä, jotka liittyvät suoraan ytimen onnistuneeseen asentamiseen.
Oma. Christopher Diaz Riveros
Tällä tavalla jokaisesta "monimutkaisesta" vaiheesta tulee "yksinkertainen" globaalilla tavalla menettämättä tarvittavia yksityiskohtia. Tämä helpottaa kokoonpanon näkyvyyttä laskematta prosessin onnistuneeseen loppuun saattamiseen tarvittavaa määrittelytasoa. Ja emme voi kieltää sitä, että kuvan on helpompi nähdä 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
Kun otetaan huomioon nämä käsitteet, projektinhallinta (kaikenlainen) helpottuu, koska keskitämme ponnistelumme sinne, missä niitä todella tarvitaan, ja jos tämä osa tehdään oikein, loput kuuluvat sen omaan painoon. Toivon, että se auttaa uteliaisuuttasi ja motivoi sinua tutkimaan BPM: ää, algoritmeja ja kuka tietää, ehkä se kannustaa sinua auttamaan minua opinnäytetyössäni. 😛 Kiitos paljon saapumisestasi ja tapaamme pian. Kippis
Hei. Kiitos tiedon jakamisesta. Minusta tuntuu, että se on jännittävä aihe, mutta se vaatii paljon tutkimustyötä ja käsitteiden toteuttamista käytännössä voidakseen sisäistää ne. Aluksi asia on hämmentävä, koska se on taipumus liittää se enemmän järjestelmän vaatimusten tunnistamisen puolelle eikä välttämättä yrityksen liiketoimintaprosesseihin eli yrityksen toimintaan. Loppujen lopuksi mielestäni kyse on enemmän ohjelmistokehittäjien roolista yrityksen liiketoiminnan mallintamisessa, jotta liiketoiminnan tehostaminen ja tehostaminen.
Hei Alexander, kiitos paljon jakamisesta. Totta puhuen, on melko monimutkainen aihe yrittää tiivistää kaikki niin pienessä tilassa, mutta jos voin auttaa hieman päästäkseni sekaannuksesta kommenttisi kanssa, on totta, että järjestelmien tulisi yrittää ratkaista vaatimukset, että on suurin mahdollinen perustoiminto, ja siinä vaiheessa on totta, että kehittäjän tulisi keskittyä korkeammalle tasolle.
Prosessien tuntemus antaa kehittäjille mahdollisuuden esittää enemmän kuin tarpeeksi järjestelmiä, ymmärtäen riittävän jotain, joka täyttää vähimmäisvaatimukset.
Koodin tyylikkyys on siinä, että pystymme ymmärtämään koko prosessin ja luomaan sen syvemmällä tavalla, missä käytetään parasta mahdollista ratkaisua, ja tämä on mahdollista vain ymmärtämällä prosessi eikä vaatimus, kuten mainitsit hyvin 🙂
Jos mallinnamme sitä vähän FOSS: n ympärille, se merkitsee paitsi ohjelmistovaatimusten tuntemista, myös sen takana olevan filosofian tuntemista ja tietämistä siitä, kuinka kuka sitä ylläpitää, ja kaiken sen prosessin tuntemuksen, joka ei vain luo tehokkaan ratkaisun ., mutta se on mahdollista ylläpitää ajan myötä 🙂
Paljon kiitoksia vielä kerran ja terveisiä.