Mindannyian hallottunk már a 80/20 szabályról, amely azt mondja, hogy sikereink (hatásaink) 80% -a csak cselekedeteink (okok) 20% -ából származik. Nos, ez az egyetemes igazság a szoftverfejlesztést is érinti, és ebben a cikkben egy kicsit kibontjuk ennek a megállapításnak az alapjait.
BPM
Az üzleti folyamatmenedzsment angol rövidítése miatt egy olyan vezetési tudományág (többek között), amely lehetővé teszi, hogy vizuálisan megértse azokat a folyamatokat, amelyeket egy vállalkozásban (vagy sok más helyen) el kell végeznie. Fő tulajdonságai közé tartozik az a tény, hogy összetett folyamatokat képes elemezni és "egyszerűvé" tenni.
Sok olyan nyílt forráskódú eszköz létezik, amelyek lehetővé teszik a BPM-diagramok fejlesztését, az egyiket, amelyet a cikkhez használtam, a BonitaSoft. Ha szeretne egy kicsit többet megtudni a folyamatmenedzsmentről, sok oktatóanyag található az interneten, és könyv található a témában. Térjünk vissza a központi témához.
Szoftver projektek
Ma már számos módszer létezik a projektek kidolgozásához, vannak mozgékony, hagyományos, vegyes stb., Stb. Egy pont mindannyiukban közös előkészítés. Mit értek ez alatt? A szoftverprojektben elért sikereinek 80% -a a teljes folyamat első 20% -án alapul, az előkészület.
Projekt előkészítése
Ez valami logikus dolog, amelyet a valóságban nagyon keveset alkalmaznak (mint sok más logikai dolog, amely a gyakorlatban logikátlan). Amikor a felkészülésről beszélünk, meg kell értenünk a probléma megértésének, a megoldás megértésének képességét és mindenekelőtt a folyamat hogy a megoldás érvényes. Az egyik dolog, ami a legkevésbé fordul elő a nem szakszerű szoftverprojektekben, a dokumentáció hiánya a témában. Ez általában a magánvállalkozásoknál jelenik meg, mivel az eladási vágy meghaladja a létrehozási folyamatot.
Mivel sokan olvassák ezeket a cikkeket, vagy kapcsolódnak a technológiához, ezért érdemes megemlíteni, hogy ha munkájuk során egy olyan céget / beszállítót találnak, amely nem felel meg a jó felkészülésnek, akkor majdnem 80% -ban biztos 😛 a projekt nem fog sikerülni.
Az absztrakció a kulcs
Ezt megtanultam a GNU / Linux használatából származó időmből, és ez újra és újra bebizonyítja, hogy kulcsfontosságú a szoftver létrehozásának folyamatában. Kapacitása absztrakt Az elegáns kód előállításához elengedhetetlen a probléma, hogy "egyszerűbb" dolgokká váljanak hosszan tartó. És talán ez az egyik fő különbség a nagy szakmai projektekben és az ellenőrzésen kívül növekvő projektekben. Az előbbiek gondolkodnak, értenek és strukturálódnak a folyamat míg a másodpercek fenntart anélkül dolgozni, hogy meg kellene értenie.
színpadias
Ez a neve annak a projektnek, amelyet a Gentoo telepítő fejleszt, mivel elképzelheti, ez meglehetősen összetett folyamat, mivel nagyszámú architektúrát támogat. Egy másik figyelembe veendő tényező a konfigurációk száma, amelyeket támogat, kernel szinten, init rendszerben stb. És mindezt azért mondom el neked, mert ez egyben a szakdolgozatom is, amelyet a tanulmányok befejezése előtt be kell fejeznem. Nyilvánvalóan nem tudok olyan programot készíteni, amely az összes lehetséges opciót szem előtt tartja ilyen rövid idő alatt (jövő év júliusáig), de legalább tudok olyanot generálni, amely lehetővé teszi egy funkcionális rendszer nagyon alapos telepítését.
A telepítési folyamat megértése
A BPM eszközöknek köszönhetően létrehozható egy folyamatdiagram, amely lehetővé teszi számunkra, hogy megértsük a Gentoo sikeres telepítéséhez szükséges lépéseket.
Saját. Christopher Diaz Riveros
Annak ellenére, hogy több folyamatot és alfolyamatot tartalmaz, nyilvánvalóan eléggé összefoglalták, és látható, hogy 18 lineáris lépésünk van. Ez azért fontos, mert egy lineáris felépítésű alkalmazást egyszerűen megvalósíthatunk, ugyanakkor szükség esetén egy vagy több szálban párhuzamosság keletkezhet.
Egy másik fontos tényező, hogy lehetővé teszi számunkra absztrakt folyamatok halmaza típusonként, például egy kernel szál meghatározása tudatja velünk, hogy vannak olyan speciális feladatok, amelyek közvetlenül kapcsolódnak a kern sikeres telepítésének folyamatához.
Saját. Christopher Diaz Riveros
Ily módon minden "komplex" lépés globálisan "egyszerű" lesz, a szükséges részletek elvesztése nélkül. Ez megkönnyíti a szerelvény láthatóságát anélkül, hogy csökkentené a folyamat sikeres befejezéséhez szükséges specifikáció szintjét. És nem tagadhatjuk, hogy könnyebb a képet látni, mint elolvasni az egész Kézikönyvet egyszerre 🙂
Időt takarít meg
Egy másik nyilvánvaló előny, hogy ha nincs közvetlenül összekapcsolt programozási nyelv, akkor logikai elemzést lehet végezni anélkül, hogy szükségszerűen elvesztegetnénk az időt a nyelv megvalósításával. Ez előnyt jelent ahhoz az időhöz képest, amelyet egy funkció megvalósításával lehet eltölteni, csak hogy kiderüljön, hogy elvetik, mert van egy hatékonyabb megoldás. Mint például az álkód megoldásai (amit sok "fejlesztő" szintén figyelmen kívül hagy, de nem szabad).
A projektek irányítása egyszerűvé vált
Ezeket a fogalmakat figyelembe véve a projektmenedzsment (bármilyen) könnyebbé válik, mert erőfeszítéseinket oda összpontosítjuk, ahol valóban szükség van rájuk, és ha ez a rész helyesen történik, a többi a saját súlya alá tartozik. Remélem, hogy segít a kíváncsiságában és motiválja Önt a BPM, az algoritmika vizsgálatára, és ki tudja, talán arra ösztönzi Önt, hogy segítsen a szakdolgozatomban 😛 Köszönöm szépen, hogy ideértek, és hamarosan találkozunk. Egészségére
Szia. Köszönjük, hogy megosztotta ismereteit. Számomra úgy tűnik, hogy ez egy izgalmas tantárgy, de sok kutatómunkát és a fogalmak gyakorlati megvalósítását igényli annak érdekében, hogy internalizálhassák őket. Eleinte a kérdés azért zavaró, mert az ember inkább a rendszer követelményeinek azonosítása mellett kapcsolja össze, és nem feltétlenül a vállalat üzleti folyamataival, vagyis a vállalat működésével. Végül azt gondolom, hogy inkább arról van szó, hogy a szoftverfejlesztők milyen szerepet töltenek be a vállalat üzletének alakításában, annak érdekében, hogy a vállalkozás működését hatékonyabbá és eredményesebbé tegyék.
Helló Sándor, nagyon köszönöm a megosztást. Az igazat megvallva kissé összetett téma, hogy mindent megpróbálok összefoglalni egy ilyen kicsi helyen, de ha egy kicsit hozzájárulhatok ahhoz, hogy elkerüljem a zavart az Ön megjegyzésével 🙂 igaz, hogy a rendszereknek meg kell próbálniuk megoldani a követelményeket, hogy a lehető legtöbb alapvető funkcionalitás, és ezen a ponton igaz, hogy a fejlesztőnek magasabb szintre kell összpontosítania.
A folyamatok ismerete lehetővé teszi a fejlesztők számára, hogy elegendőnél több rendszert mutassanak be, eléggé megértve valamit, ami megfelel a lehető legkisebb követelményeknek.
A kód eleganciája abban rejlik, hogy megértheti a teljes folyamatot, és létrehozhatja azt mélyebben, ahol a lehető legjobb megoldást alkalmazzák, és ez csak akkor lehetséges, ha valóban megértjük a folyamatot, nem pedig a követelményt, amint azt Ön is jól említette 🙂
Ha egy kicsit az FOSS-on modellezzük, az nemcsak a szoftverkövetelmény, hanem a mögöttes filozófia ismeretét is magában foglalja, és annak ismeretét, hogy hogyan fogja ezt fenntartani, ki, és a folyamat mindazon ismereteit, amelyek nemcsak hatékony megoldást generálnak. , de idővel fenn lehet tartani
Még egyszer nagyon köszönöm és üdvözletem.