Ons het almal gehoor van die 80/20-reël, die een wat sê dat 80% van ons sukses (gevolge) slegs uit 20% van ons optrede (oorsake) kom. Hierdie universele waarheid het ook 'n invloed op sagteware-ontwikkeling, en in hierdie artikel gaan ons 'n bietjie van die grondbeginsels van hierdie stelling gebruik.
Index
BPM
Besigheidsprosesbestuur, vir sy akroniem in Engels, is 'n bestuursdissipline (onder andere) waarmee u die prosesse wat in 'n onderneming (of op baie ander plekke) uitgevoer moet word, visueel kan verstaan. Die belangrikste eienskappe daarvan is die feit dat dit ingewikkelde prosesse kan ontleed en 'eenvoudig' kan maak.
Daar is baie open source-instrumente waarmee u BPM-diagramme kan ontwikkel, die een wat ek vir hierdie artikel gebruik het, is BonitaSoft. As u 'n bietjie meer wil leer oor prosesbestuur, is daar baie tutoriale op die internet en boeke oor die onderwerp. Laat ons nou terugkeer na die sentrale onderwerp.
Sagtewareprojekte
Vandag is daar baie metodologieë om projekte te ontwikkel, daar is rats, tradisioneel, gemeng, ens, ens. Een punt wat hulle almal gemeen het, is voorbereiding. Wat bedoel ek hiermee? Dat 80% van u sukses in hierdie sagtewareprojek gebaseer sal wees op die eerste 20% van die hele proses, die voorbereiding.
Voorbereiding van 'n projek
Dit is iets logies wat in werklikheid baie min toegepas word (soos baie ander logiese dinge wat in die praktyk onlogies is). As ons oor voorbereiding praat, moet ons die vermoë verstaan om die probleem te verstaan, die oplossing te verstaan en bowenal, die proses dat die oplossing van toepassing is. Een van die dinge wat die minste in onprofessionele sagtewareprojekte voorkom, is die gebrek aan dokumentasie oor die onderwerp. Dit kom gewoonlik in private ondernemings voor aangesien die begeerte om te verkoop die skeppingsproses oorskry.
Aangesien baie van diegene wat hierdie artikels lees, werk of verband hou met tegnologie, is dit die moeite werd om te noem dat as hulle op 'n stadium in hul werkslewe 'n onderneming / verskaffer vind wat nie goed voorbereid is nie, is dit byna 80% seker 😛 dat die projek dit sal nie regkom nie.
Abstraksie is die sleutel
Dit is iets wat ek van my tyd af geleer het met behulp van GNU / Linux, en dit bewys dat dit telkens weer die sleutel is tot die skepping van sagteware. Die kapasiteit van abstrak probleme om dit in 'meer' eenvoudige 'dinge te omskep, is noodsaaklik om elegante kode te kan genereer, en bowenal langdurige. En miskien is dit een van die belangrikste verskille van groot professionele projekte en projekte wat buite beheer groei. Eersgenoemde dink, verstaan en struktureer die proses terwyl die sekondes hulle hou werk sonder dat u dit hoef te verstaan.
verhoog
Dit is die naam van die projek wat die Gentoo-installateur ontwikkel, soos u kan voorstel, dit is nogal 'n ingewikkelde proses, aangesien dit 'n groot aantal argitekture ondersteun. 'N Ander faktor om in ag te neem, is die aantal konfigurasies wat dit ondersteun, op kernvlak, init-stelsel, ens. En ek vertel dit alles, want dit is ook my tesisprojek wat ek moet voltooi voordat ek klaar is met studeer. Dit is duidelik dat ek nie binne 'n kort tydjie (tot Julie volgende jaar) 'n program kan maak wat absoluut alle moontlike opsies oorweeg nie, maar ten minste kan ek een genereer wat dit moontlik maak om 'n funksionele stelsel op 'n baie basiese manier te installeer.
Verstaan die installasieproses
Danksy die BPM-instrumente kan 'n prosesdiagram gegenereer word wat ons toelaat om die stappe te verstaan wat nodig is vir die suksesvolle installering van Gentoo op 'n rekenaar.
Eie. Christopher Diaz Riveros
Ondanks die feit dat dit verskeie prosesse en subprosesse bevat, is dit natuurlik redelik opgesom en kan gesien word dat ons 18 lineêre stappe het. Dit is belangrik omdat 'n toepassing met 'n lineêre struktuur eenvoudig is om te implementeer, en terselfdertyd kan parallelisme in een of meer van die drade gegenereer word, indien nodig.
Nog 'n belangrike faktor is dat dit ons toelaat abstrak stel prosesse volgens tipe, byvoorbeeld om 'n kerndraad te definieer, laat ons weet dat daar spesifieke take binne is wat direk verband hou met die proses om 'n kern suksesvol te installeer.
Eie. Christopher Diaz Riveros
Op hierdie manier word elke 'komplekse' stap 'n 'eenvoudige' op 'n globale manier, sonder om die nodige besonderhede te verloor. Dit vergemaklik die sigbaarheid van die vergadering sonder om die spesifikasievlak te verlaag wat nodig is om die proses suksesvol af te handel. En ons kan nie ontken dat dit makliker is om die beeld te sien as om die hele Handboek tegelyk te lees nie
Bespaar tyd
'N Ander ooglopende voordeel is dat dit nie moontlik is om 'n logiese analise uit te voer sonder om tyd te mors om die taal te implementeer deur nie 'n programmeertaal met direkte verbinding te hê nie. Dit is 'n voordeel in vergelyking met die hoeveelheid tyd wat aan die implementering van 'n funksie bestee kan word om uit te vind dat dit weggegooi word omdat daar 'n doeltreffender oplossing is. Soos wat die oplossings in pseudo-kode sou wees (iets wat ook deur baie "ontwikkelaars" geïgnoreer word, maar nie behoort te wees nie).
Die regie van projekte is maklik gemaak
As u hierdie konsepte in ag neem, word projekbestuur (van watter aard ook al) makliker, want ons fokus ons pogings waar dit regtig nodig is, en as hierdie deel korrek gedoen word, val die res onder sy eie gewig. Ek hoop dit help u nuuskierigheid en motiveer u om BPM, algoritmiese navorsing te ondersoek en wie weet, miskien sal dit u aanmoedig om my te help met my tesis 😛 Baie dankie dat u hierheen gekom het en ons sal mekaar binnekort sien. Cheers
2 kommentaar, los joune
Hi. Dankie dat u u kennis gedeel het. Dit lyk vir my asof dit 'n opwindende onderwerp is, maar dat dit baie navorsingswerk verg en die konsepte prakties moet toepas om dit te kan internaliseer. Aanvanklik is die kwessie verwarrend omdat 'n mens meer geneig is om dit aan die kant van die vereistes vir 'n stelsel te identifiseer en nie noodwendig met die sakeprosesse van die onderneming nie, dit wil sê hoe die onderneming werk. Uiteindelik dink ek dat dit meer gaan oor die rol wat sagteware-ontwikkelaars speel in die modellering van die onderneming, om die onderneming meer effektief en effektief te maak.
Hallo Alexander, baie dankie vir die deel. Om die waarheid te sê, is dit 'n ietwat komplekse onderwerp om alles in so 'n klein ruimte te probeer opsom, maar as ek 'n bietjie kan bydra om uit u verwarring te kom met u opmerking 🙂 is dit waar dat stelsels moet probeer om die vereistes op te los, dat is die mees moontlike basiese funksionaliteit, en op daardie stadium is dit waar dat 'n ontwikkelaar op 'n hoër vlak moet fokus.
Kennis van die prosesse stel ontwikkelaars in staat om meer as genoeg stelsels aan te bied en genoeg te verstaan as iets wat aan die minimum moontlike vereistes voldoen.
Die elegansie van die kode lê daarin dat u die volledige proses kan verstaan en op 'n dieper manier kan genereer, waar die beste moontlike oplossing toegepas word, en dit is slegs moontlik deur die proses regtig te verstaan eerder as die vereiste, soos u goed genoem het. 🙂
As ons dit 'n bietjie rondom die FOSS modelleer, beteken dit nie net dat u die sagtewarevereiste ken nie, maar ook die filosofie daaragter, en weet hoe dit sal onderhou word, deur wie en al die kennis van die proses wat nie net 'n doeltreffende oplossing oplewer nie. ., maar dit sal moontlik wees om oor tyd te handhaaf 🙂
Nogmaals baie dankie en groete.