Başarımızın (etkilerimizin)% 80'inin eylemlerimizin (nedenlerimizin) yalnızca% 20'sinden kaynaklandığını söyleyen 80/20 kuralını hepimiz duymuşuzdur. Eh, bu evrensel gerçek aynı zamanda yazılım geliştirmeyi de etkiliyor ve bu makalede bu ifadenin temellerinden biraz bahsedeceğiz.
BPM
İş Süreçleri Yönetimi, İngilizce kısaltması nedeniyle, bir işletmede (veya başka birçok yerde) gerçekleştirilmesi gereken süreçleri görsel olarak anlamanıza izin veren (diğer şeylerin yanı sıra) bir yönetim disiplinidir. Temel nitelikleri arasında karmaşık süreçleri analiz edebilmesi ve "basit" hale getirebilmesidir.
BPM diyagramları geliştirmenize izin veren birçok açık kaynaklı araç var, bu makale için kullandığım BonitaSoft. Süreç yönetimi hakkında biraz daha fazla bilgi edinmek istiyorsanız, internette birçok öğretici ve konuyla ilgili kitaplar var. Şimdi ana konuya geri dönelim.
Yazılım projeleri
Günümüzde proje geliştirmek için birçok metodoloji var, çevik, geleneksel, karma vb. Var. Hepsinin ortak noktalarından biri, hazırlık. Bununla ne demek istiyorum? Bu yazılım projesindeki başarınızın% 80'inin tüm sürecin ilk% 20'sine dayanacağını, hazırlık.
Bir proje hazırlamak
Bu, gerçekte çok az uygulanan mantıklı bir şeydir (pratikte mantıksız olan diğer birçok mantıksal şey gibi). Hazırlıktan bahsettiğimizde sorunu anlama, çözümü anlama ve her şeyden önce, süreç çözümün geçerli olduğu. Profesyonel olmayan yazılım projelerinde en az bulunan şeylerden biri, konuyla ilgili dokümantasyon eksikliğidir. Bu, genellikle satış arzusu yaratma sürecini aştığı için özel şirketlerde görülür.
Bu makaleleri okuyanların çoğu çalıştığı veya teknolojiyle ilgili olduğu için, çalışma hayatlarının bir noktasında iyi bir hazırlığı karşılamayan bir şirket / tedarikçi bulurlarsa, neredeyse% 80 emin olduklarını belirtmekte fayda var 😛 proje yürümeyecek.
Soyutlama anahtardır
Bu, GNU / Linux kullanarak zamanımdan öğrendiğim bir şey ve yazılım yaratma sürecinde anahtar olduğunu defalarca kanıtlıyor. Kapasitesi Öz sorunları daha "basit" şeylere dönüştürmek, zarif kodlar üretebilmek için çok önemlidir ve hepsinden önemlisi uzun ömürlü. Ve belki de bu, kontrolden çıkan büyük profesyonel projelerin ve projelerin temel farklılıklarından biridir. İlki düşünür, anlar ve yapılandırır süreç saniyeler tutarlar anlamak zorunda kalmadan çalışmak.
Aşama
Bu, Gentoo yükleyicisinin geliştirdiği projenin adıdır, tahmin edebileceğiniz gibi, bu oldukça karmaşık bir süreçtir, çünkü çok sayıda mimariyi desteklemektedir. Dikkate alınması gereken diğer bir faktör, çekirdek düzeyinde, init sisteminde vb. Desteklediği konfigürasyonların sayısıdır. Ve size tüm bunları söylüyorum çünkü bu aynı zamanda benim tez projem, çalışmayı bitirmeden bitirmem gerekiyor. Açıkçası, bu kadar kısa sürede (gelecek yılın Temmuz ayına kadar) tüm olası seçenekleri kesinlikle düşünen bir program yapamam, ancak en azından işlevsel bir sistemin çok basit bir şekilde kurulmasına izin veren bir program oluşturabilirim.
Kurulum sürecini anlamak
BPM araçları sayesinde, Gentoo'nun bir bilgisayara başarılı bir şekilde yüklenmesi için gerekli adımları anlamamıza izin veren bir süreç diyagramı oluşturulabilir.
Kendi. Christopher Diaz Riveros
Çeşitli süreçler ve alt süreçler içermesine rağmen açıkça özetlenmiş ve 18 doğrusal adımımız olduğu görülebiliyor. Bu önemlidir, çünkü doğrusal bir yapıya sahip bir uygulamanın uygulanması kolaydır ve aynı zamanda paralellik, gerekirse bir veya daha fazla iş parçacığında oluşturulabilir.
Bir diğer önemli faktör de bize izin vermesidir. Öz türe göre işlem grupları, örneğin, bir çekirdek iş parçacığını tanımlamak, içinde bir çekirdeği başarılı bir şekilde kurma işlemiyle doğrudan ilgili olan belirli görevler olduğunu bilmemizi sağlar.
Kendi. Christopher Diaz Riveros
Bu şekilde, her "karmaşık" adım, gerekli ayrıntıları kaybetmeden, küresel bir şekilde "basit" bir adım haline gelir. Bu, işlemi başarılı bir şekilde tamamlamak için gereken özellik seviyesini düşürmeden montajın görünürlüğünü kolaylaştırır. Ve el kitabının tamamını bir defada okumaktan daha kolay olduğunu inkar edemeyiz 🙂
Zamandan tasarruf
Bir başka bariz avantaj ise, doğrudan bağlı bir programlama diline sahip olmamakla, dili uygulamak için zaman kaybetmeden mantık analizi gerçekleştirmenin mümkün olmasıdır. Bu, bir özelliğin uygulanmasına harcanabilecek zaman miktarına kıyasla, yalnızca daha verimli bir çözüm olduğu için atılacağını öğrenmek için bir avantajdır. Sözde koddaki çözümler gibi (birçok "geliştirici" tarafından da göz ardı edilen ancak olmaması gereken bir şey).
Projeleri yönetmek kolaylaştı
Bu kavramları hesaba katarsak, proje yönetimi (her türlü) daha kolay hale gelir, çünkü çabalarımızı gerçekten ihtiyaç duyulan yere odaklıyoruz ve bu kısım doğru yapılırsa geri kalanı kendi ağırlığının altına düşer. Umarım merakınıza yardımcı olur ve sizi BPM, algoritmalar hakkında araştırma yapmaya motive eder ve kim bilir, belki de tezimde bana yardımcı olmaya teşvik eder here Buraya geldiğiniz için çok teşekkür ederim ve yakında görüşeceğiz. Şerefe
Selam. Bilgilerinizi paylaştığınız için teşekkür ederiz. Bana öyle geliyor ki heyecan verici bir konu ama içselleştirebilmek için çok fazla araştırma çalışması ve kavramların pratiğe geçirilmesi gerekiyor. İlk başta konu kafa karıştırıcıdır, çünkü kişi onu daha çok bir sistemin gereksinimlerini belirleme tarafında ilişkilendirme eğilimindedir ve illa ki şirketin iş süreçleriyle, yani şirketin nasıl çalıştığı ile değil. Sonuç olarak, işin daha verimli ve etkili olmasını sağlamak için yazılım geliştiricilerin şirketin işini modellemede oynadıkları rolle ilgili olduğunu düşünüyorum.
Merhaba İskender, paylaştığınız için çok teşekkür ederim. Gerçeği söylemek gerekirse, her şeyi bu kadar küçük bir alanda özetlemeye çalışmak biraz karmaşık bir konudur, ancak yorumunuzla karışıklıktan kurtulmak için biraz katkıda bulunabilirsem systems Sistemlerin gereksinimleri çözmeye çalışması gerektiği doğrudur, olası en temel işlevselliktir ve bu noktada bir geliştiricinin daha yüksek bir seviyeye odaklanması gerektiği doğrudur.
Süreçlerin bilgisi, geliştiricilerin, mümkün olan minimum gereksinimleri karşılayan bir şey olduğunu yeterince anlayarak, yeterli sistemden fazlasını sunmalarına olanak tanır.
Kodun zarafeti, tüm süreci anlayabilmekte ve onu mümkün olan en iyi çözümün uygulandığı daha derin bir şekilde üretebilmekte yatmaktadır ve bu, yukarıda da belirttiğiniz gibi, gereklilikten ziyade süreci gerçekten anlamakla mümkündür. 🙂
Biraz FOSS etrafında modellersek, sadece yazılım gereksinimini bilmekle kalmayıp, arkasındaki felsefeyi ve nasıl, kim tarafından korunacağını ve yalnızca verimli bir çözüm üretmekle kalmayan süreç hakkındaki tüm bilgileri de içerir. ., ancak zamanla sürdürmek mümkün olacak 🙂
Tekrar çok teşekkür ederim ve selamlar.