Uzmanlar, işi tamamlamak için son tarihleri ​​doğru bir şekilde belirlemeyi nasıl öğreneceklerini yanıtlıyor. Planlama (bilgi işlem) - Yenilikçi teknolojiler ve çözümler merkezinin planlama (bilgi işlem) teknik direktörü "Jet Infosystems"

Önceki algoritmanın değiştirilmiş bir versiyonu, kalan en kısa yürütme süresi algoritmasıdır. Bu algoritmaya göre zamanlayıcı her seferinde kalan yürütme süresi en kısa olan işlemi seçer. Bu durumda görevin tamamlanma süresinin önceden bilinmesi de gerekir. Yeni bir görev geldiğinde, bu görevin toplam yürütme süresi mevcut görevin kalan yürütme süresiyle karşılaştırılır. Yeni görevin yürütme süresi daha kısa ise mevcut süreç askıya alınır ve kontrol yeni göreve aktarılır. Bu şema, kısa isteklere hızlı bir şekilde hizmet vermenizi sağlar.

Üç seviyeli planlama

Toplu işleme sistemleri, şekilde gösterildiği gibi üç seviyeli planlamaya izin verir. Sisteme yeni görevler geldiğinde, bunlar öncelikle diskte depolanan bir kuyruğa yerleştirilir. Giriş erişim zamanlayıcısı bir görev seçer ve bunu sisteme aktarır. Kalan görevler kuyrukta kalır.

Bir iş sisteme girer girmez ona karşılık gelen bir süreç oluşturulacak ve hemen işlemciye erişim için rekabet etmeye başlayabilecektir. Ancak, çok fazla işlemin olması ve bunların hepsinin belleğe sığmaması mümkündür, bu durumda bazılarının disk belleğine alınması mümkündür. İkinci planlama düzeyi, hangi işlemlerin bellekte saklanabileceğini ve hangilerinin diskte saklanabileceğini belirler. Yaptığı şey bu bellek zamanlayıcı .

Bellek zamanlayıcı, hangilerinin belleğe taşınacağına karar vermek için düzenli aralıklarla diskteki işlemlere bakar. Zamanlayıcı tarafından kullanılan kriterler arasında şunlar yer almaktadır:

1. İşlemin diske taşınmasının veya diskten yüklenmesinin üzerinden ne kadar zaman geçti?

2. İşlem ne kadar süredir CPU'yu kullanıyor?

3. Sürecin boyutu nedir (küçük süreçler karışmaz)?

4. Sürecin önemi nedir?

Üçüncü planlama düzeyi, hazır durumdaki işlemlerin işlemciye erişmesine izin vermekten sorumludur. Bir “zamanlayıcı”dan bahsettiğimizde genellikle şunu kastederiz: CPU zamanlayıcı . Bu zamanlayıcı, hem kesintili hem de kesintisiz olarak duruma uygun herhangi bir algoritmayı kullanır. Bu algoritmaların bazılarına zaten baktık ve diğerleriyle daha sonra tanışacağız.

Etkileşimli sistemlerde planlama.

Döngüsel planlama.

En eski, en basit, en adil ve en sık kullanılanlardan biri döngüsel planlama algoritmasıdır. Her işleme, zaman dilimi adı verilen belirli bir miktarda işlemci süresi verilir. Zaman dilimi sonunda süreç hala çalışıyorsa sonlandırılır ve kontrol başka bir sürece aktarılır. Tabii eğer süreç erken bloke edilir veya sonlandırılırsa bu noktada bir kontrol geçişi meydana gelir. Round-robin planlamanın uygulanması basittir. Zamanlayıcının yalnızca hazır durumdaki süreçlerin bir listesini tutması gerekir. Bir işlem zaman sınırına ulaştığında listenin sonuna gönderilir.

Bu algoritmanın tek ilginç yönü kuantumun uzunluğudur. Bir işlemden diğerine geçiş biraz zaman alır - kayıtları ve hafıza haritalarını kaydetmek ve yüklemek, tabloları ve listeleri güncellemek, hafıza önbelleğini kaydetmek ve yeniden yüklemek vb. gereklidir. Sonuç şu şekilde formüle edilebilir: çok küçük bir kuantum yol açacaktır süreçlerin sık sık değiştirilmesi ve verimliliğin küçük olması, ancak çok büyük bir kuantum, kısa etkileşimli isteklere yavaş yanıt verilmesine neden olabilir. Yaklaşık 2 0 -5 0 ms'lik bir kuantum değeri genellikle makul bir uzlaşmadır.

Öncelikli planlama.

Round robin planlamanın tüm süreçlerin eşit olduğu yönünde önemli bir varsayımı vardır. Çok sayıda kullanıcısı olan bir bilgisayarda durum böyle olmayabilir. Örneğin bir üniversitede önce dekanlara, sonra profesörlere, sekreterlere, temizlikçilere ve ondan sonra da öğrencilere hizmet verilmelidir. Bu tür dış faktörlerin dikkate alınması ihtiyacı öncelikli planlamaya yol açmaktadır. Temel fikir basittir: Her prosese bir öncelik atanır ve kontrol, en yüksek önceliğe sahip hazır prosese aktarılır.

Birkaç kuyruk.

İlk öncelikli zamanlayıcılardan biri CTSS sisteminde (uyumlu zaman paylaşımlı sistem) uygulandı.CTSS sistemindeki ana sorun, IBM 7094 bilgisayarının bellekte yalnızca bir işlemi tutabilmesi nedeniyle işlem değiştirmenin çok yavaş olmasıydı. Her anahtar mevcut sürecin diske aktarılması anlamına geliyordu

ve yeni işlemi diskten okumak. CTSS'nin geliştiricileri, işlemciyle sınırlı işlemlere küçük zaman dilimleri verilmesine kıyasla daha büyük bir zaman dilimi verilmesi durumunda verimliliğin daha yüksek olacağını hemen fark etti, ancak çoğu zaman. Bu bir yandan bellekten diske aktarım sayısını azaltacak, diğer yandan da daha önce gördüğümüz gibi tepki süresinde bozulmaya yol açacaktır.

Sonuç olarak öncelik sınıflarına sahip bir çözüm geliştirildi. En yüksek öncelikli sınıftaki işlemlere bir kuantum tahsis edildi, bir sonraki sınıftaki işlemlere iki kuantum tahsis edildi, sonraki sınıftaki işlemlere dört kuantum tahsis edildi vb. Bir süreç, ayrılan sürenin tamamını kullandığında, daha düşük bir öncelik sınıfına taşındı. sınıf.

Örnek olarak 100'den fazla kuanta hesaplaması gereken bir süreci düşünün. Önce bir kuantum verilecek, sonra diske pompalanacak. Bir dahaki sefere 2 kuanta alır, sonra 4, 8,16, 32, 64, ancak 64 kuantadan sadece 37'sini kullanır. Bu durumda, 100 yerine sadece 7 transfere (başlangıç ​​yükü dahil) ihtiyaç duyulacaktır. Round-robin algoritması kullanılarak ihtiyaç duyulur. Ayrıca öncelik sırası derinleştikçe süreç daha az sıklıkta başlayacak ve CPU'nun daha kısa süreçlere geçmesine neden olacaktır.

“En kısa süreç bir sonraki süreçtir”

En Kısa Görev Önce algoritması, toplu işleme sistemlerinde ortalama geri dönüş süresini en aza indirdiğinden, onu etkileşimli sistemlerde de kullanmak istenebilir. Bir dereceye kadar bu mümkündür. Etkileşimli süreçler çoğunlukla "bir komutu beklemek, bir komutu yürütmek, bir komutu beklemek, bir komutu yürütmek..." modelini takip eder. Her komutun yürütülmesini ayrı bir görev olarak ele alırsanız, genel ortalama yanıtı en aza indirebilirsiniz. Önce en kısa görevi çalıştırarak zamanı kısaltın. Tek sorun

bekleme süreçlerinden hangisinin en kısa olduğunu anlamaktır.

Yöntemlerden biri, sürecin önceki davranışına dayalı olarak süreç uzunluğunun tahmin edilmesine dayanmaktadır. Bu durumda tahmini süresi en kısa olan süreç başlatılır. Komutun beklenen yürütme zamanının T 0 ve beklenen bir sonraki yürütme zamanının T 1 olduğunu varsayalım. Bu sürelerin ağırlıklı toplamını aT 0 + (1 - a)T 1 alarak alarak zaman tahminini iyileştirmek mümkündür. a için uygun değeri seçerek, tahmin algoritmasının önceki çalıştırmaları hızlı bir şekilde unutmasını veya tam tersine bunları uzun süre hatırlamasını sağlayabiliriz. a = 1/2 alarak bir dizi tahmin elde ederiz:

T 0, T 0/2 + T 1/2, T 0/4 + T 1/4 + T 2/2, T 0/8 + T 1/8 + T 2/4 + T 3/2.

Üç çalıştırmadan sonra T 0'ın tahmindeki ağırlığı 1/8'e düşecektir.

Bir serideki bir sonraki değeri, önceki değerin ve önceki tahminin ağırlıklı ortalaması yoluyla tahmin etme yöntemine genellikle yaşlanma denir. Bu yöntem önceki değerlerden tahmin yapılmasının gerekli olduğu birçok durumda uygulanabilir. Yaşlandırmayı uygulamanın en kolay yolu a = 1/2'dir. Her adımda ihtiyacınız olan

mevcut tahmine yeni bir değer ekleyin ve toplamı ikiye bölün (1 bit sağa kaydırarak).

Garantili planlama.

Planlamaya temel olarak farklı bir yaklaşım, kullanıcılara gerçek sözler vermek ve ardından bunları yerine getirmektir. İşte söylemesi ve tutması kolay bir söz: Bir işlemciyi n kullanıcıyla paylaşırsanız, size işlemci gücünün 1/n'si verilecektir.

Ve bir kullanıcının ve n işlemcinin çalıştığı bir sistemde, her biri 1/n işlemci döngüsü alacaktır.

Bu sözü yerine getirmek için sistemin, her işlemin oluşturulduğu andan itibaren işlemler arasındaki CPU tahsisini takip etmesi gerekir. Sistem daha sonra işlemin hak sahibi olduğu CPU kaynaklarının miktarını (örneğin, oluşturulduğundan bu yana geçen sürenin n'ye bölümü gibi) hesaplar. Artık işleme verilen sürenin, hak ettiği süreye oranını hesaplayabiliriz. Sonuçta ortaya çıkan 0,5 değeri, sürecin tahsis edilen miktarın yalnızca yarısını aldığı anlamına gelir; 2,0 ise sürecin olması gerekenden iki kat fazlasını aldığı anlamına gelir. Daha sonra en küçük orana sahip işleme geçilir.

en yakın komşusununkinden daha büyük olmayacak.

Piyango planlaması.

Algoritma, işlemci de dahil olmak üzere çeşitli kaynaklara erişim için işlemlere piyango biletlerinin dağıtılmasına dayanmaktadır. Planlayıcının bir karar vermesi gerektiğinde, rastgele bir piyango bileti seçilir ve sahibi kaynağa erişim sağlar. CPU erişimi açısından "piyango" saniyede 50 kez gerçekleşebilir ve kazanan 20 ms CPU süresine sahip olur.

Kazanma olasılığını artırmak için daha önemli işlemlere ek biletler verilebilir. Yalnızca 100 bilet varsa ve bunların 20'si tek bir işlemdeyse, işlemci süresinin %20'sini alır. Öncelik 40'ın ne anlama geldiğini değerlendirmenin çok zor olduğu öncelik planlayıcının aksine, piyango planlamada her şey açıktır. Her süreç, sahip olduğu biletlerin yüzdesine yaklaşık olarak eşit bir kaynak yüzdesi alacaktır.

Piyango planlamasının birçok ilginç özelliği vardır. Örneğin, bir süreç oluşturma sırasında birden fazla bilet alırsa, bir sonraki piyangoda kazanma şansı bilet sayısıyla orantılıdır.

İletişim süreçleri gerekirse bilet alışverişi yapabilir. Dolayısıyla, eğer bir istemci işlemi bir sunucu işlemine bir mesaj gönderir ve ardından bloke ederse, sunucunun başlama şansını artırmak için tüm biletlerini sunucu işlemine iletebilir. Sunucu işlemi bittiğinde tüm biletleri geri döndürebilir.

Adil planlama.

Şu ana kadar her sürecin sahibinin kim olduğundan bağımsız olarak kontrol edildiğini varsaydık. Bu nedenle, 1. kullanıcı 9 işlem oluşturursa ve 2. kullanıcı - 1. işlem oluşturursa, o zaman dönüşümlü planlama kullanıldığında veya eşit öncelikler durumunda, 1. kullanıcı işlemcinin %90'ını, 2. kullanıcı ise yalnızca 10'unu alacaktır.

Bu tür durumlarla karşılaşmamak için bazı sistemler planlama öncesinde sürecin sahibine dikkat eder. Bu modelde her kullanıcı işlemciden belirli bir pay alır ve zamanlayıcı bu gerçeğe göre bir süreç seçer. Örneğimizde her kullanıcının

İşlemcinin %50'sini vaat ettilerse, işlem sayısına bakılmaksızın işlemcinin %50'sini alacaklar.

Gerçek zamanlı sistemlerde planlama.

Gerçek zamanlı sistemlerde zaman önemli bir rol oynar. Çoğu zaman, bir veya daha fazla harici fiziksel aygıt giriş sinyalleri üretir ve bilgisayarın belirli bir süre içinde bunlara yeterli düzeyde yanıt vermesi gerekir.

Gerçek zamanlı sistemler ikiye ayrılır zor gerçek zamanlı sistemler , bu, her görev için kesin son tarihlerin varlığı anlamına gelir (karşılanmaları gerekir) ve esnek gerçek zamanlı sistemler Zaman çizelgesinin ihlal edilmesinin istenmediği ancak kabul edilebilir olduğu durumlar. Her iki durumda da program, her biri öngörülebilir olan çeşitli süreçlere bölünmüştür. Bu süreçler çoğu zaman kısadır ve bir saniye içerisinde işlerini tamamlarlar. Harici bir sinyal göründüğünde, programın sürdürüldüğünden emin olması gereken kişi planlamacıdır.

Sistemin yanıt vermesi gereken dış olaylar şu şekilde ayrılabilir: periyodik(düzenli aralıklarla meydana gelir) ve düzenli olmayan(öngörülemeyen bir şekilde meydana gelir). Sistemin işlemesi gereken birkaç periyodik olay akışı olabilir. Her olayın işlenmesi için gereken süreye bağlı olarak sistem, tüm olayları zamanında işleyemeyebilir.

İlgili bilgi.

Geliştiricilerin, özellikle de deneyimsiz olanların, görevleri tamamlamak için son tarihler belirlemeleri istendiğinde çoğu zaman kafası karışır. Ancak planlama yeteneği, yalnızca işte değil hayatta da yardımcı olan çok faydalı ve gerekli bir beceridir. Uzmanlara doğru planlamayı ve projeleri zamanında teslim etmeyi nasıl öğreneceklerini sormaya karar verdik.

Kısa sonuçları makalenin sonunda bulabilirsiniz.

Bir geliştiricinin, bir görevi tamamlamak için gereken süreyi tahmin etmek için genellikle birkaç parametreyi aynı anda hesaba katması gerekir:

1. Bu tür görevleri yerine getirme ve bu teknoloji yığınıyla çalışma deneyimi. Temelde yeni bir şey yapmanız gerekiyorsa, değerlendirmenizde özellikle dikkatli olmanız gerekir.
2. Bu müşteriyle çalışmayı deneyimleyin. Müşteriyi tanıyarak bazı ek gereksinimleri ve değişikliklerin kapsamını kabaca tahmin edebilirsiniz.
3. Çalışacağınız kodun kalitesi. Bu en etkili faktördür, çünkü her şey uzun zaman alabilir ve genellikle planlandığı gibi gitmeyebilir. Projenin testleri varsa, her yerde yalnızca açık bağımlılıklar vardır ve işlevsellik iyi yalıtılmıştır, her şey o kadar korkutucu değildir. Testler olmadan eski kodlarla veya örtülü bağımlılıklarla aşırı yüklenmiş kodlarla çalışıyorsanız durum çok daha kötü. "Sihirli işlevler" (koddan son çağrı yığınını görmek zor olduğunda) ve kod çoğaltma (bazı işlevleri değiştirmek için birkaç bağımsız bölümü düzenlemeniz gerektiğinde) gibi şeyler de işleri karmaşık hale getirebilir.

İşin son teslim tarihlerini nasıl yeterince tahmin edeceğinizi öğrenmek için sürekli pratik yapmanız gerekir. Çalışmamın başlangıcında tam olarak şunu yaptım: Kimse gerektirmese bile, gelen herhangi bir görevi tamamlamak için gereken süreyi tahmin ettim ve ardından tahminimi ne kadar doğru bir şekilde yapmayı başardığıma baktım. Görevi tamamlarken hangi eylemlerin daha uzun sürdüğünü kaydetti. Eğer bir şey süreyi önemli ölçüde arttırdıysa, bu anı hatırladım ve sonraki değerlendirmelerde dikkate aldım.

Yalnızca iş için gereken sürenin objektif bir değerlendirmesine, mücbir sebep durumlarını kapsayacak şekilde küçük bir marj eklenmelidir. Genellikle ana görevin tamamlanma yüzdesi olarak değerlendirilir, ancak bu herkes için farklıdır: bazıları zamanın %20'sini, bazıları %10'unu ve bazıları da %50'sini ekler.

Ayrıca, her ciddi son teslim tarihi ihlalinden sonra kaçırılan son teslim tarihlerinin nedenlerini analiz etmek de faydalıdır. Nitelikleriniz yoksa zayıf noktalarınız üzerinde çalışmanız gerekir. Sorun organizasyonelse, normal çalışmasını neyin engellediğini anlayın.

Yükselt İndir

, yenilikçi teknolojiler ve çözümler merkezinin teknik direktörü "Jet Infosystems"

İşin süresi ve bireysel görevler de dahil olmak üzere bir projenin emek yoğunluğunu değerlendirme yöntemlerine çok sayıda makale ayrılmıştır. Ancak bu durum yine de hem proje ekibi içinde hem de müşteriyle iletişimde çatışmalara neden oluyor.

Değerlendirmede asıl yardımcı deneyimdir. Yeni görevi daha önce yapılmış olanlarla bir şekilde karşılaştırmaya çalışın. Eğer bir rapor hazırlıyorsanız, geçmişte benzer bir raporun ne kadar sürdüğüne bakın. Yeni bir şey yapıyorsanız, onu bilinen parçalara ayırmayı ve bunları değerlendirmeyi deneyin. Görev tamamen yeniyse, çalışmaya zaman ayırın (daha da iyisi, bu zamanı görevi belirleyen kişiyle koordine edin).

Ekteki aşamalara dikkat edin - bir hizmet geliştirmeniz gerekiyorsa, değerlendirme aynı zamanda birim testini de içermelidir (ve belki yalnızca birim testini değil), test verilerinin hazırlanması biraz zaman alacaktır. Diğer hizmetlerle entegrasyonu vb. düşünmelisiniz. Bulduğunuz kusurları kendiniz veya test uzmanlarının yardımıyla düzeltmek için zaman tanıyın. “Görünmez” görevlerde çok fazla zaman harcanabilir. Örneğin, geliştirme için bir değerlendirme ve test için bir değerlendirme vardır, ancak bir eserin test için aktarılması, standların konuşlandırılmasını içerebilir. Bu nedenle hiçbir şeyi kaçırmamak için tüm süreci zihinsel olarak görselleştirmek önemlidir.

Karmaşıklığı belirledikten sonra, paralel giden diğer görevleri ve etkinlikleri unutmadan, yeni çalışmaları takvime dahil etmek gerekir.

Ve unutmayın ki planlar işe yaramaz ama planlama paha biçilemezdir. Planları zamanında ayarlamayı öğrenin, ilgili herkesi bilgilendirin ve kaçırılan son teslim tarihlerinin hiç kimse için sürpriz olmaması için konuyu zamanında iletin.

Yükselt İndir

Kısa bir formda cevaplanamayacak bir soru. Eğer basit olsaydı, son teslim tarihlerinin kaçırılması sorunu yaşanmazdı.

Geliştirme son tarihlerini daha öngörülebilir hale getirmek için öncelikle programcıların neden sürekli hata yaptığını anlamalıyız.

İlk neden, bir programcının yaptığı görevlerin çoğunun bir dereceye kadar benzersiz olmasıdır. Yani, büyük olasılıkla programcı benzer bir görevi ilk kez yapacaktır. Bu çalışmanın ne kadar süreceği konusunda pek bir fikri yok. Bu, sağlam deneyime sahip bir programcıysa ve benzer bir görevi yerine getirmek zorundaysa, değerlendirmesi gerçeğe daha yakın olacaktır.

Basit bir benzetme yapalım; eğer hiç hendek kazmadıysanız, 30 cm genişliğinde, 60 cm derinliğinde ve 20 metre uzunluğunda bir hendek kazmanın ne kadar süreceğini tam olarak söyleyemezsiniz. Daha önce kazdıysanız, çalışma süresine ilişkin tahmininiz işin gerçek süresine çok daha yakın olacaktır.

İkinci neden ise programcıların doğası gereği iyimser olmalarıdır. Yani geliştirici, bir görevi değerlendirirken, onun için bir uygulama seçeneği seçerken ve iyileştirmeleri değerlendirirken her şeyin beklediği gibi çalışacağını bekler. Ve yol boyunca karşılaşacağı sorunları düşünmüyor. Çoğu zaman bunları öngöremez. Örneğin, bir programcının üçüncü taraf açık kaynak yazılım kitaplığını kullanarak gerçekleştirebileceği bir görev var. Değerlendirme aşamasında internette buldu, açıklamasını okudu - ona yakışıyor. Hatta bu kütüphaneyi kullanabilmek için yapması gereken iş miktarını da doğru bir şekilde tahmin etmişti. Ancak kendi yazılım ürününün ortamında bu kütüphanede bir hata oluşacağını hiç öngörmemişti.

Geliştiricinin yalnızca kütüphanenin kullanımını koduna dahil etmesi değil, aynı zamanda kütüphanenin kendisindeki bir hatayı da düzeltmesi gerekecek. Ve çoğu zaman geliştirici, hatalarını düzeltmek için zaman sağlamaz. İstatistikler, test etme ve hataları düzeltmenin kodlamaya harcanan zamanın yaklaşık %50'sini alabileceğini gösteriyor. Rakam, geliştiricinin niteliklerine, ortama ve kullanılan geliştirme uygulamalarına bağlıdır (örneğin, birim testler bu süreyi önemli ölçüde azaltır ve geliştirme görevinin nihai süresi/işgücü yoğunluğu daha azdır).

Kazıcı benzetmesine dönersek, kazıcı küreğinin kırılacağını ve yeni bir kesim aramak için iki saat harcamak zorunda kalacağını beklemiyordu.

Üçüncü neden ise öngörülemeyen gereksinimlerdir. Müşterilerin yazılım geliştirmeyi karşılaştırmayı bu kadar sevdikleri malzeme üretiminin başka hiçbir alanında bu kadar yeni gereksinim akışı yoktur. 20 metreden 19'unu kazan bir kazıcının geçişini hayal edin ve müşteriden hendek düz bir çizgide değil, kol uzunluğu 97 santimetre olan bir yılanın gitmesi yönündeki isteğini duydu.

Tüm bunlarla nasıl başa çıkılır ve bu belirsizlik koşullarında nasıl yaşanır? Belirsizliği azaltmak ve zaman rezervleri oluşturmak.

Beklentilerinizi gerçeğe yaklaştırmanın en kolay yolu eğlenceli Pi temel kuralını kullanmaktır. Geliştiriciden bir tahmin aldıktan sonra (zaman veya emek yoğunluğu açısından), bunu Pi (= 3,14159) ile çarpmanız gerekir. Geliştirici değerlendirmeyi ne kadar deneyimli yaptıysa bu oran o kadar düşük olabilir.

Orijinal problemi, boyutu 4 saatten fazla olmayan küçük görevlere ayırma uygulaması zorunludur. Ayrıştırma ne kadar ayrıntılı olursa, tahminin gerçek karmaşıklığa/süreye yakın olma şansı da o kadar yüksek olur.
Rezerv tahsisine dönersek bu sürenin proje bitiminde ayrılması gerekir. Bir rezerv oluşturmak ve bunu her göreve dahil etmek kötü bir uygulamadır. Parkinson Yasası “İş, kendisine ayrılan tüm zamanı doldurur” kuralına sıkı sıkıya uyulur.

Kısaca özetlemek gerekirse, işin tamamlanması için son tarihlerin doğru bir şekilde belirlenebilmesi için aşağıdaki eylemler faydalı olacaktır:

• görevi mümkün olduğunca ayrıntılı adımlara bölerek bir iş ayrıştırması gerçekleştirin;
• prototipleme yapmak;
• Daha önce öngörülemeyen gereksinimlerin uygulanmasını sınırlandırın. Bu, bunların yapılmasına gerek olmadığı anlamına gelmez, ancak bu gerekliliklerin vurgulanması ve bunların uygulanmasına ilişkin zamanlama ve maliyetteki değişiklikler konusunda müşteriyle mutabakata varılması tavsiye edilir;
• çözümü stabilize etmek için gereken süreyi hesaba katın;
• Birim testleri yazmak gibi kod kalitesini artırmak için uygulamalar kullanın;
• genel bir rezerv belirleyin.

Bir gerçeğin tahmininizi %30 oranında aşması durumunda bunun çok iyi bir sonuç olduğunu unutmayın.

Yükselt İndir

En doğru değerlendirme için, gerçek gelişim konusunda ve özellikle belirli bir alanda deneyime ihtiyacınız vardır. Ancak planlamadaki hatalardan ve işi müşteriye teslim ederken sorunlardan kaçınmanıza yardımcı olacak genel kurallar da vardır. Bu kuralları şu şekilde açıklayabilirim.

Öncelikle sorunu anlamanız gerekiyor. Bu çok açık görünüyor ve doğrudan zamanlama tahminleriyle ilgili değil ama aslında kilit bir nokta. Ciddi büyük projelerde bile başarısızlığın ve gecikmenin ana faktörlerinden biri gereksinimlerin tanımlanmasındaki sorundur. Yeni başlayan geliştiriciler için maalesef bu ciddi bir sorundur - teknik özellikleri okumazlar veya çok seçici bir şekilde okuyup anlarlar (on puan üzerinden beşini hatırladılar ve tamamladılar ve geri kalanını sonucu gönderirken hatırladılar). Yanlış anlaşılan bir görevin zamanında doğru şekilde uygulanamayacağı açıktır.

Sonraki adım, geliştirme süresinin kendisini tahmin etmektir. Programlamanın özelliği, tamamen aynı görevlerin bulunmamasıdır. Bu, işimizi daha ilginç hale getiriyor ancak son teslim tarihlerini tahmin etmek daha zor. Ayrıştırma burada iyi işliyor; karmaşık, benzersiz bir problemi bir dizi küçük, tanıdık alt görevlere bölmek. Ve bunların her biri zaten saatler içinde oldukça yeterli bir şekilde değerlendirilebiliyor. Alt görevlerin tahminlerini toplayalım ve görevin tamamı için bir tahmin elde edelim.

Kural olarak, böyle bir tahmin yalnızca kodlamanın maliyetini içerir. Bu, elbette, geliştirmenin en önemli kısmıdır, ancak tek kısım olmaktan uzaktır (ve çoğu zaman en hacimli kısmı da değildir). Görevin tam olarak tamamlanması aynı zamanda spesifikasyonun okunmasını ve açıklığa kavuşturulmasını, meslektaşlar veya müşteriyle toplantıları, hata ayıklamayı ve test etmeyi, dokümantasyonun hazırlanmasını, sonucun teslim edilmesini (müşteriye gösteri ve onun yorumlarına göre olası değişiklikler) içerir. Bu eylemleri tamamlamanızın tam olarak ne kadar süreceğini yalnızca deneyim size söyleyecektir. İlk başta, en azından hesaplamalarda bunları dikkate almayı unutmamak önemlidir ve daha deneyimli meslektaşlarınızdan yaklaşık bir süre tahmini isteyebilirsiniz.

Böylece, kodlama için işçilik maliyetlerinin bir tahminini alıyoruz, ek iş maliyetlerinin bir tahminini ekliyoruz ve görevi tamamlamak için gereken süreye ilişkin tahminimizi elde ediyoruz. Ama hepsi bu değil! Görevin planlanan tamamlanma tarihini belirtmeniz gerekir. İşçilik maliyetini (saat cinsinden) 8 saate bölüp güncel tarihe eklemek hata olur. Gerçek uygulamada, bir geliştirici hiçbir zaman (tamam, neredeyse hiçbir zaman) zamanın %100'ünü belirli bir görev üzerinde çalışmaz. Kesinlikle başka işlere zaman harcayacaksınız - önemli, ancak asıl işle doğrudan ilgili değil. Örneğin, meslektaşlara yardım etmek, eğitim vermek, rapor yazmak vb. Tipik olarak, planlama sırasında çalışma süresinin% 60-70'inin doğrudan mevcut proje üzerinde çalışarak harcandığına inanılmaktadır. Ayrıca, görev üzerinde sürekli çalışmanızı engelleyecek olası gecikmeleri de hesaba katmanız gerekir. Örneğin, bunun için diğer insanlarla (meslektaşlarınız, müşteriler) etkileşime girmeniz gerekiyorsa, onların uygunluk durumlarını, çalışma programlarını vb. dikkate alın.

Bana göre geliştiricinin son teslim tarihlerini tahmin etme ve karşılamada sorunlardan kaçınmasına yardımcı olacak temel kurallar şunlardır. Ayrıca önemli olan hem görevlerin uygulanmasında hem de değerlendirmede kendi deneyiminizi biriktirmektir. Örneğin, bir görevi tamamladıktan sonra ilk tahmininizi gerçek son tarihlerle karşılaştırmak ve geleceğe yönelik sonuçlar çıkarmak çok faydalıdır. Ve elbette diğer insanların deneyimlerini incelemeye değer. Konuyla ilgili S. McConnell'in "Bir yazılım projesinin maliyeti ne kadardır" ve S. Arkhipenkov'un "Yazılım proje yönetimi üzerine dersler" kitaplarını tavsiye ederim.

Yükselt İndir

Son teslim tarihlerini tahmin ederken ve planlarken şunları yapmalısınız:

1. Görevi küçük işlevsel parçalara ayırın, böylece bu parçalardan her birinin geliştirilmesinin ne kadar süreceği net bir şekilde anlaşılsın.
2. Ayrışmaya paralel olarak, işlevsellikle ilgili olarak problem tanımında açıklanmayan ek sorular da mutlaka ortaya çıkacaktır. Bu tür soruların cevabının alınması işin kapsamı ve dolayısıyla zamanlamayla doğrudan ilgili olduğundan gereklidir.
3. Nihai değerlendirmeye belirli bir risk yüzdesi ekleyin. Bu ampirik olarak belirlenir. Örneğin %10-15 riskle başlayabilirsiniz.
4. Bir programcının bir görevi tamamlamak için günde kaç saat ayırmaya istekli olduğunu anlayın.
5. Nihai tahmini, günlük ayırdığımız saat sayısına bölerek uygulama için gereken gün sayısını elde ederiz.
6. Takvime ve tamamlanması gereken gün sayısına odaklanıyoruz. Programcının görev üzerinde çalışamayacağı hafta sonları ve diğer günlerin yanı sıra işin başlangıç ​​tarihini de dikkate alırız (geliştirici her zaman aynı gün görevi üstlenmeye hazır değildir). Böylece işin başlangıç ​​ve bitiş tarihini almış oluyoruz.

Yükselt İndir

Şirketimizde görev planlaması her zaman birkaç aşamadan geçer. İş tarafında ise yıl için 5-6 stratejik hedef belirliyoruz. Bunlar üst düzey görevlerdir; örneğin bazı parametreleri yüzde o kadar artırmak. Daha sonra şirketin çeşitli bölümleri, tüm BT ekipleri için iş görevlerini formüle eder. Bu görevlerin son tarihleri, genellikle tüm ekip üyeleri (yönetici, analist, geliştirici ve test uzmanı) tarafından oluşturulan kaba bir başlangıç ​​tahmini alır. İşletme bu değerlendirmeyi aldıktan sonra, şirketin stratejik hedeflerine göre görevleri önceliklendirir. Kesişen stratejik hedefler buna yardımcı olur; onlarla birlikte hepimizin ortak bir amaç için çalıştığımız aşikar hale gelir; birisinin yalnızca kendi yönüne doğru ilerlemesi gibi bir durum yoktur. Son teslim tarihlerine göre doğru tahmin edilen görevlerden sprintler topluyoruz. Bazı takımlar için bunlar üç ayda bir, diğerleri için ise aylıktır. Ön tahminlere göre bir sonraki sprintte yer alacak çeşitli görevler için takımlar doğru bir tahminde bulunur. Büyük görevler, her biri için belirli bir icracının sorumlu olduğu daha düşük seviyeli görevlere bölünmüştür ve doğru bir değerlendirme yapan kişi odur.

Bu aşamada hataları düzeltmek için zaman ayırmayı unutmamak önemlidir çünkü yalnızca hiçbir şey yapmayanlar hata yapmaz. Hem Ürün Sahipleri hem de ticari müşteriler bunu çok iyi anlıyor. Aynı zamanda, gereken süre yeterli olmalıdır: Basit bir görev için çok uzun bir son tarih belirleyen geliştiriciyi kimse anlamayacaktır; kendisinden, kararını gerekçelendirmesi istenecektir. En zor şey, işletmeye yeniden düzenlemenin neden zaman aldığını açıklamaktır. Zaman zaman bunu başardığımız için şirketimize minnettarız, çünkü sonuçta yeniden düzenleme, altyapının basitleştirilmesine ve kodun sıraya konulmasına yol açar, bu da sistemin kararlılığını artırır ve geliştirmeyi önemli ölçüde hızlandırabilir. yeni işlevler.

Bazen değerlendirmede hatalar hala ortaya çıkar. Altyapısı gelişmiş büyük şirketlerde geliştirme departmanının bundan tamamen kurtulması bence mümkün değil. Bu durumda geliştiricinin, yöneticisini olup bitenler hakkında derhal bilgilendirmesi ve karşılığında işletmeyi uyarmayı ve şirketin genel planlarındaki bir şeyi "tekrar oynatmayı" başarması önemlidir. Bu modda çalışmak, 5 gün süren işi çılgınca 3 günde yapmaya çalışıp, bu acele nedeniyle ortaya çıkan çok sayıda hatanın içinde boğulmaktan çok daha doğrudur.

Yükselt İndir

Sorunun her iki kısmına da doğru cevap [bir projenin nasıl doğru planlanacağını ve zamanında teslim edileceğini öğrenmek - Ed.] - deneyim. "Zen'i bilmenin" başka yolu yoktur. Karar teorisine göre, herhangi bir doğru sonuca yalnızca halihazırda mevcut olan bir dizi verinin analizine dayanarak ulaşılabilir. Ve ne kadar çok veri varsa, nihai tahmin ve değerlendirme o kadar doğru olur.

Herbert Shaw'un sözleriyle: "Tecrübe, bir adamın önceden ne kadar aptal olduğunu öğrendiği okuldur." Bu bizi oldukça basit bir sonuca götürür: Eğer bir programcı halihazırda elindeki görevle ilgili deneyime sahipse ona güvenebilir; değilse "meslektaşlarının" deneyimine güvenebilir.

Daha sonra, son teslim tarihlerinin doğrudan planlanmasının, özellikle geliştirme aşamasında insanların çok çok zayıf bir şekilde başa çıktığı bir görev olduğunu anlamalısınız. Vade tarihlerini tahmin ederken, orijinal tahmine "düzeltme faktörlerini" dahil etmek iyi bir uygulama olarak kabul edilir. Bu ölçüm, geliştiricinin deneyimine ve proje içinde çözülen görevlerin belirsizlik derecelerinin toplamına bağlı olarak 1,5 ila 3 arasında değişebilir.

Yükselt İndir

Son teslim tarihlerini belirlerken birçok faktörü dikkate almak önemlidir.

Örneğin iş deneyimi. Önümüzdeki çalışmanın kapsamını ne kadar net anlıyorsunuz? Daha önce buna benzer bir şey yaptınız mı? Ne kadar çok deneyim olursa işin o kadar hızlı tamamlanacağı açıktır.

İyi yazılmış bir teknik şartname, son teslim tarihlerinin belirlenmesinde önemli bir rol oynar. Bizim bölgemizde bu konuda işler çok zor. Çoğu zaman müşterinin kendisi ne istediğini bilmiyor, bu yüzden fazladan bir veya iki gün harcamanızı, ancak müşterinin istenen sonuç hakkında net bir fikir sahibi olmasını sağlamanızı öneririm. Bu anlayışın karşılıklı olması önemlidir. Ve ancak bundan sonra miktar ve şartları müzakere etmeye başlayabilirsiniz.

Ayrıca her zaman riskleri de dahil edin. Yeni başlayanlar için tahmini tamamlanma süresini ikiyle çarpmanızı öneririm. Sonuçta, bir projeyi daha sonra teslim edip itibarınızı zedelemek yerine, bir projeyi planlanandan önce teslim etmek ve müşterinin gözünde bir uzman olarak büyümek daha iyidir.

Yükselt İndir

Genel bir öneri, geliştiricinin görevleri doğru bir şekilde nasıl ayrıştıracağını öğrenmesi, her zaman olası tuzakları araması, kendi deneyimlerine güvenmesi ve görevin belirtilen süre içinde çözülememesi durumunda müşterileri ve meslektaşlarını zamanında uyarmayı unutmaması gerektiğidir. çerçeve.

Net bir plan oluşturmak, tek bir görevi tamamlamak için son tarihi belirlemekten çok daha zordur. Aynı zamanda sadece projeyi zamanında teslim etmek değil, geliştirdiğiniz sistemin iş sorunlarını doğru bir şekilde çözmesini sağlamak da önemlidir. Burada BT ekiplerine RUP ve MSF'den SCRUM ve diğer Agile formatlarına kadar çeşitli yazılım geliştirme metodolojileri yardımcı oluyor. Aletlerin seçimi çok kapsamlıdır ve müşterilerimizin çoğu, projede onlarla nasıl çalışacağımızı, hangi ilkelere bağlı kalacağımızı önceden anlamak ister.

Bu arada, Agile konusu bugün hem iş dünyasına hem de kamu sektörüne yönelik bireysel projelere yakın hale geliyor, çünkü bu metodolojinin ilkeleri projelerin çok hızlı bir şekilde uygulanmasına ve her yinelemede müşteri beklentilerinin yönetilmesine olanak tanıyor. Örneğin, Çevik bir ekipte müşteriyle neredeyse hiç uzun süreli tartışma yapılmaz. Bir açılır listenin ne kadar hızlı göründüğü gibi gereksiz teknik ayrıntıları anlatan onlarca sayfayı unutun. Müşteriye sistemin ara versiyonunu deneme fırsatı verin, o zaman birbirinizi anlamanız çok daha kolay olacaktır.

Agile ekibi her şeyi birlikte planlar ve belirli bir sorunu çözmek için ihtiyaç duyulacak en uygun iş gücü düzeyini belirler. Örneğin, her katılımcının belirli bir görev için gerekli işçilik maliyetlerine ilişkin değerlendirmesini anonim olarak sunduğu tekniklerden birine "Poker Planlama" adı verilir. Bunun ardından ekip, görevin ortalama ağırlığını hikaye puanı veya adam-saat cinsinden belirliyor ve “kim neyi seviyor” ilkesine göre görev dağılımı yapıyor. Aynı zamanda, ekip her gün 15 dakikalık bir toplantı için bir araya geliyor ve herkes birkaç dakika içinde mevcut görevlerinin durumu hakkında konuşuyor ve ortaya çıkan zorlukları bildirmek de dahil. Ekip, tespit edilen sorunu hızlı bir şekilde düzeltir, böylece müşteri, programcının çalışmasının bir sonraki aşamasına mümkün olan en kısa sürede bakar. Geliştiriciler, ekibi bir kez daha rahatsız etme konusundaki isteksizlik veya sorunu kendi başlarına çözmeye yönelik nafile girişimler nedeniyle görevlerin tamamlanmasını geciktirmiyor ve değerli zamanı öldürmüyor. Bu arada, bu tür mini durumlarda geliştiricilerin en iyi taraflarını gösterme, işinize sorumlu bir şekilde yaklaştığınızı gösterme arzusu vardır. Gerçekten motive ediyor ve öz disiplin sağlıyor.

(periyodik etkinlik durumunda tamamlanana kadar veya etkileşimli etkinlik durumunda sistem yanıt verip ilk kullanıcı çıkışını verene kadar işten geçen süre dahil edilir); veya maksimizasyon adalet(her işlem için eşit miktarda CPU süresi veya daha genel olarak her işlemin önceliğine ve iş yüküne göre karşılık gelen süreler). Uygulamada, bu hedefler sıklıkla birbiriyle çatışır (örneğin, verim ve gecikme), dolayısıyla zamanlayıcı uygun bir ödünleşim yapacaktır. Tercih, kullanıcının ihtiyaç ve hedeflerine bağlı olarak yukarıda belirtilen hususlardan herhangi biri ile ölçülür.

OS/360 ve ardılları

AIX

AIX Sürüm 4'te iş parçacığı planlama ilkesi için üç olası ayar vardır:

• Birincisi, ilk çıkar: Bu politikaya sahip bir iş parçacığı planlandıktan sonra, tamamlanana kadar çalışır; engellenmediği, işlemcinin kontrolünden gönüllü olarak vazgeçmediği veya daha yüksek öncelikli bir iş parçacığı gönderilebilir hale gelmediği sürece. Yalnızca sabit öncelikli iş parçacıkları FIFO zamanlama ilkesine sahip olabilir.
• Round Robin: Bu, 10 ms zaman dilimlerine göre döngü yapan AIX Sürüm 3 devre planlayıcısına benzer. Bir PP iş parçacığı bir zaman diliminin sonunda kontrole sahip olduğunda, aynı önceliğe sahip iş parçacıkları kuyruğunun kuyruğuna doğru hareket eder. Yalnızca sabit öncelikli iş parçacıklarının Round Robin planlama politikası olabilir.
• DİĞER: Bu politika POSIX1003.4a tarafından uygulama tarafından tanımlanmıştır. AIX Sürüm 4'te bu politika, sabit olmayan öncelikli iş parçacıklarına uygulanması dışında RR'ye eşdeğer olarak tanımlanır. Her kesme için çalışan bir iş parçacığının öncelik değerinin yeniden hesaplanması, bir iş parçacığının öncelik değeri başka bir iş parçacığından daha yükseğe çıktığı için kontrolü kaybedebileceği anlamına gelir. Bu AIX Sürüm 3 davranışıdır.

İş parçacıkları şu anda birden çok eşzamansız işlemden oluşan uygulamaların ilgisini çekmektedir. Bu uygulamalar çok iş parçacıklı bir yapıya dönüştürüldüğü takdirde sisteme hafif bir yük getirebilir.

AIX 5 şu planlama politikalarını uygular: FIFO, hepsini bir kez deneme ve adil bir kez bir kez deneme. FIFO politikası üç farklı uygulamadan oluşur: FIFO, FIFO2 ve FIFO3. AIX'te hep bir kez deneme politikası SCHED_RR olarak adlandırılır ve adil bir kez deneme politikası SCHED_OTHER olarak adlandırılır.

Linux

Linux2.4

Yine Kolivas tarafından oluşturulan Brain Fuck Scheduler (BFS), CFS'ye bir alternatiftir.

ÜcretsizBSD

FreeBSD, öncelikleri 0-255 aralığında olan çok seviyeli bir geri bildirim kuyruğu kullanır. 0-63 arası kesintiler için, 64-127 çekirdeğin üst yarısı için, 128-159 gerçek zamanlı kullanıcı iş parçacıkları için, 160-223 zaman paylaşımlı kullanıcı iş parçacıkları için ve 224-255 boş kullanıcı iş parçacıkları için ayrılmıştır. Ayrıca Linux gibi aktif bir kuyruk kurulumu kullanıyor ancak aynı zamanda boş bir kuyruğu da var.

giriiş

Üretim organizasyonu çalıştayının amacı teorik bilgiyi genişletmek ve derinleştirmek, üretimin organizasyonu ve planlanması ile ilgili pratikte en sık karşılaşılan sorunların çözümü için gerekli becerileri kazandırmaktır.

Atölye, kursun ana bölümlerine yönelik görevleri içerir. Her konunun başında kısa metodolojik talimatlar ve teorik bilgiler, çözümleri ile tipik problemler ve bağımsız çözüme yönelik problemler sunulmaktadır.

Her konudaki metodolojik talimatların ve kısa teorik bilgilerin varlığı, bu atölyeyi uzaktan eğitim için kullanmanıza olanak tanır.

Üretim çevrim süresinin hesaplanması

Üretim döngüsünün süresi, üretim sürecinin verimliliğinin bir göstergesi olarak hizmet eder.

Üretim döngüsü- Hammaddelerin piyasaya sürülmesinden bitmiş ürünlerin piyasaya sürülmesine kadar üretim sürecinde emek nesnelerinin kalma süresi.

Üretim döngüsü şunlardan oluşur: çalışma saatleri, emeğin harcandığı süre ve mola zamanları. Molalar, onlara neden olan nedenlere bağlı olarak aşağıdakilere ayrılabilir:

1) açık doğal veya teknolojik - ürünün doğasına göre belirlenir;

2) organizasyonel(vardiyalar arasında molalar).

Üretim döngüsünün süresi aşağıdaki bileşenlerden oluşur:

T döngüsü = T bunlar + T yiyor + T TR + T k.k. + T ay. + T m.ts.

Nerede T onlar– teknolojik operasyonların zamanı;

yemek yemiyorum - doğal süreçlerin süresi (kurutma, soğutma vb.);

t tr – emek nesnelerinin ulaşım süresi;

tk.k. – kalite kontrol süresi;

t m.o – interoperatif bakım süresi;

t m.c. – mağazalar arası depolarda depolama süresi;

(Tüç T k.k. ile birleştirilebilir T ay).

Üretim çevrim süresinin hesaplanması, üretim türüne bağlıdır. Seri üretimde üretim döngüsünün süresi, ürünün üretimde olduğu zamana göre belirlenir;

T döngüsü = T M'de,

Nerede T V– serbest bırakma stroku;

M- işyeri sayısı.

Altında serbest bırakma vuruşuÜretilen bir ürünün piyasaya sürülmesi ile bir sonraki ürünün piyasaya sürülmesi arasındaki zaman aralığını anlamak gerekir.

Serbest bırakma vuruşu formülle belirlenir

t in = Teff /V,

Nerede Tef– fatura dönemi için (vardiya, gün, yıl) işçinin etkin zaman fonu;

İÇİNDE– aynı dönemdeki çıktı hacmi (doğal birimler cinsinden).

Örnek: T cm = 8 saat = 480 dakika; T başına = 30 dakika; → Teff = 480 – – 30 = 450 dk.

B = 225 adet; → T= 450/225 = 2 dk.

İşlemenin partiler halinde gerçekleştirildiği seri üretimde teknolojik döngünün süresi ürün birimi başına değil partinin tamamı için belirlenir. Üstelik bir partiyi üretime sokma yöntemine bağlı olarak farklı çevrim süreleri elde ederiz. Üretimde ürünleri taşımanın üç yolu vardır: sıralı, paralel ve karışık (seri-paralel).

BEN. Şu tarihte: ardışık Parçaları taşırken, sonraki her işlem yalnızca bir önceki işlem bittikten sonra başlar. Parçaların sıralı hareketi için çevrim süresi şuna eşit olacaktır:

Nerede N – işlenen partinin parça sayısı;

t adetBen- bir operasyon için parça zaman oranı;

C ben– kişi başına düşen iş sayısı Ben operasyon;

M– teknolojik süreç operasyonlarının sayısı.

5 adetten oluşan ürün partisi verilmektedir. Parti ardışık olarak 4 işlemden geçirilir; İlk ameliyatın süresi 10 dakika, ikincisi 20 dakika, üçüncüsü 10 dakika, dördüncüsü ise 30 dakikadır (Şekil 1).

Resim 1

T döngü = T son = 5·(10+20+10+30) = 350 dk.

Parçaların sıralı olarak hareket ettirilmesi yöntemi, ekipmanın aksama olmadan çalışmasını sağlama avantajına sahiptir. Ancak dezavantajı, bu durumda üretim döngüsünün süresinin en uzun olmasıdır. Ayrıca şantiyelerde ek üretim alanı gerektiren önemli parça stokları oluşturulmaktadır.

II. Şu tarihte: paralel Partinin hareketi sırasında, tek tek parçalar çalışma istasyonlarında tutulmaz, tüm partinin işlenmesinin tamamlanması beklenmeden tek tek hemen bir sonraki operasyona aktarılır. Böylece, bir parça grubunun paralel hareketi ile her iş yerinde, aynı partinin farklı parçaları üzerinde eş zamanlı olarak çeşitli işlemler gerçekleştirilir.

Ürünlerin paralel hareketi ile bir partinin işlem süresi keskin bir şekilde azalır:

dl .

Nerede n n– parça sayısı toplu aktarım(nakliye partisi), yani bir operasyondan diğerine aynı anda aktarılan ürün sayısı;

Uzunluk – en uzun çalışma döngüsü.

Bir ürün grubunu paralel olarak piyasaya sürerken, tüm partinin parçaları yalnızca uzun işlemlerin kısa işlemleri takip ettiği işyerlerinde sürekli olarak işlenir. Kısa operasyonların uzun operasyonları takip ettiği durumlarda; daha uzun süre (örneğimizde üçüncü işlem) bu işlemler kesintili olarak gerçekleştirilir, yani. ekipman boşta. Burada, önceki (uzun) işlem buna izin vermediğinden, bir parça partisi gecikmeden hemen işlenemez.

Örneğimizde: N= 5, T 1 = 10; T 2 = 20; T 3 = 10; T 4 = 30; İle= 1.

T buhar = 1·(10+20+10+30)+(5-1)·30=70+120 = 190 dk.

Parçaların paralel hareket şemasını ele alalım (Şekil 2):

şekil 2

III. Tüm işlemlerde bir partinin ayrı ayrı parçalarının işlenmesindeki kesintileri ortadan kaldırmak için, paralel seri veya karışık parçaların (işlendikten sonra) tek tek veya "taşıma" partileri (birkaç parça) halinde, herhangi bir işyerinde operasyonların yürütülmesini kesintiye uğratmayacak şekilde bir sonraki operasyona aktarıldığı bir başlatma yöntemi. Karma yöntemde işlemin sürekliliği sıralı yöntemden, parçanın işlendikten hemen sonra işlemden operasyona geçişi ise paralel yöntemden alınır. Karma bir üretime başlatma yöntemiyle döngü süresi formülle belirlenir.

çekirdek .

kor nerede? – en kısa çalışma döngüsü (her bir bitişik işlem çiftinden);

M-1 – kombinasyon sayısı.

Sonraki işlem öncekinden daha uzun veya eşit süreye sahipse, bu işlem, önceki işlemde ilk parça işlendikten hemen sonra tek tek başlatılır. Aksine bir sonraki işlem bir öncekinden daha kısa olursa parça aktarımı sırasında burada kesintiler meydana gelir. Bunları önlemek için, bir sonraki operasyonda çalışmayı sağlamak için yeterli miktarda bir taşıma rezervinin biriktirilmesi gerekir. Bu noktayı grafikte pratik olarak bulmak için, partinin son kısmını aktarmanız ve yürütme süresini sağa kaydırmanız gerekir. Partideki diğer tüm parçaların işlem süresi grafiğin solunda gösterilmektedir. İlk parçanın işlenmesinin başlangıcı, önceki işlemden gelen taşıma birikiminin bu işleme aktarılması gerektiği anı gösterir.

Bitişik operasyonların süresi aynıysa, bunlardan yalnızca birinin kısa veya uzun olduğu kabul edilir (Şekil 3).

Figür 3

T son çiftler = 5·(10+20+10+30)-(5-1)·(10+10+10) = 350-120 = 230 dk.

Üretim çevrim süresini azaltmanın ana yolları şunlardır:

1) Üretilen tasarımın üretilebilirliğini artırarak, bilgisayar kullanarak ve ileri teknolojik süreçleri tanıtarak ürünlerin imalatındaki emek yoğunluğunu azaltmak.

2) İşgücü süreçlerinin rasyonel organizasyonu, işyerlerinin uzmanlaşma ve işbirliğine dayalı olarak düzenlenmesi ve bakımı, üretimin kapsamlı mekanizasyonu ve otomasyonu.

3) Üretim sürecinin bilimsel organizasyon ilkelerinin rasyonel kullanımına dayalı olarak işyerinde çeşitli planlı ve plansız molaların azaltılması.

4) Artan basınç, sıcaklık, sürekli işleme geçiş vb. sonucunda reaksiyonların hızlanması.

5) Taşıma, depolama ve kontrol süreçlerinin iyileştirilmesi ve bunların zamanında işleme ve montaj süreciyle birleştirilmesi.

Üretim döngüsünün süresini azaltmak, üretimi organize etmenin ciddi görevlerinden biridir, çünkü işletme sermayesinin cirosunu etkiler, işçilik maliyetlerini azaltır, depolama alanını azaltır, nakliye ihtiyacını vb. etkiler.

Görevler

1 Üretim sürecinde sıralı, paralel ve seri-paralel hareket türleriyle 50 parçanın işlem döngüsünün süresini belirleyin. Parçaların işlenmesi süreci, süresi sırasıyla minimum olan beş işlemden oluşur: T 1 =2; T 2 =3; T 3 =4; T 4 =1; T 5 =3. İkinci işlem iki makinede, diğerlerinin her biri bir makinede gerçekleştirilir. Transfer partisinin büyüklüğü 4 adettir.

2 Üretim sürecinde sıralı, paralel ve seri-paralel hareket türleriyle 50 parçanın işlem döngüsünün süresini belirleyin. Parçaların işlenmesi süreci, süresi sırasıyla min olan dört işlemden oluşur: T 1 =1; T 2 =4; T 3 =2; T 4 =6. Dördüncü işlem iki makinede, diğerlerinin her biri bir makinede gerçekleştirilir. Transfer partisinin büyüklüğü 5 adettir.

3 Üretim sürecinde 200 adetlik bir parti parça paralel-sıralı hareketle işlenir. Parçaların işlenmesi süreci, süresi sırasıyla minimum olan altı işlemden oluşur: T 1 =8; T 2 =3; T 3 =27; T 4 =6; T 5 =4; T 6 =20. Üçüncü işlem üç makinede, altıncı işlem iki makinede ve geri kalan işlemlerin her biri bir makinede gerçekleştirilir. Üretimdeki hareketin paralel ardışık versiyonunun yerini paralel bir versiyon alırsa, bir parça partisi için işlem döngüsünün süresinin nasıl değişeceğini belirleyin. Transfer partisinin büyüklüğü 20 adettir.

4 Üretim sürecinde 300 adetlik bir parti parça paralel-sıralı hareketle işlenmektedir. Parçaların işlenmesi süreci, süresi sırasıyla minimum olan yedi işlemden oluşur: T 1 =4; T 2 =5; T 3 =7; T 4 =3; T 5 =4; T 6 =5; T 7 =6. Her işlem bir makinede gerçekleştirilir. Transfer partisi – 30 adet. Gelişen üretim teknolojisinin bir sonucu olarak, üçüncü operasyonun süresi 3 dakika, yedinci operasyonun süresi ise 2 dakika kısaltıldı. Bir parça grubunun işlem döngüsünün nasıl değiştiğini belirleyin.

5 adet 5 parçadan oluşan bir parti işlenmemiş parça verilir. Grup 4 işlemden geçiyor: İlkinin süresi 10 dakika, ikincisinin süresi 20 dakika, üçüncüsü 10 dakika, dördüncüsü 30 dakika. Sıralı hareketle analitik ve grafiksel yöntemlerle çevrim süresini belirleyin.

6 Dört parçadan oluşan bir grup işlenmemiş parça verilmiştir. Grup 4 işlemden geçiyor: İlkinin süresi 5 dakika, ikincisinin süresi 10 dakika, üçüncüsü 5 dakika, dördüncüsü 15 dakika. Paralel hareketle analitik ve grafiksel yöntemlerle çevrim süresini belirleyin.

7 5 parçadan oluşan bir parti işlenmemiş parça verilir. Grup 4 işlemden geçiyor: İlkinin süresi 10 dakika, ikincisinin süresi 20 dakika, üçüncüsü 10 dakika, dördüncüsü 30 dakika. Seri-paralel hareket için çevrim süresini analitik ve grafiksel yöntemlerle belirleyin.

8 180 parçalık bir ürün grubunun işlenmesi için teknolojik döngünün süresini belirleyin. hareketinin paralel ve sıralı varyantları ile. İşleme süreci grafikleri oluşturun. Transfer partisinin büyüklüğü 30 adettir. Operasyonlardaki zaman standartları ve iş sayıları aşağıdaki gibidir.

Önceki bölümlerde açıklanan her şey daha çok sürecin kendi zamanındaki soruna ilişkin daha fazla araştırmaya ve çok daha az ölçüde pratik uygulamalara yönelikti. Bu boşluğu doldurarak, bir sürecin gelişimiyle ilgili istatistiksel verilere dayanarak sürecin doğru zamanını hesaplamanın yollarından birinin ana hatlarını çizeceğiz.

Durumu gerçek bir x değişkeni ile karakterize edilen tek boyutlu bir süreci ele alalım. Sürecin dinamiklerine ilişkin gözlemlerin astronomik t zamanında gerçekleştirildiğini varsayalım, böylece t = t k ve x = x k, k =1, ..., n sabit gözlem anları ve karşılık gelen değerlerdir. süreç belirtiyor. (t k, Xk) noktalarından geçen veya bunlara "en iyi yaklaşımı" sağlayan eğriler oluşturmayı mümkün kılan birçok farklı matematiksel yöntem vardır. Bu şekilde elde edilen x = x(t) fonksiyonları, zihnimizde söz konusu sürecin gök cisimlerinin mekanik hareketine bağlı olduğu ve dolayısıyla durumunun astronomik zaman t ile ifade edildiği izlenimini doğurmaktadır. Bu sonuç dikkate alınabilir; sürecin ilerleyişini tahmin etmeye çalışırken sürekli zorluklar ortaya çıkmasaydı. Gök cisimlerinin mekanik hareketleriyle doğrudan ilişkili olmayan çok sayıda farklı süreç için, gözlem aralığı dışında x = x(t) fonksiyonu kullanılarak elde edilen teorik tahminler, sonraki deneysel verilerden önemli ölçüde sapmaya başlar. Genellikle teori ile deney arasındaki tutarsızlığın nedenini, başarısız seçilmiş bir işleme yöntemiyle açıklamaya çalışırlar ancak konunun özü bu olmayabilir.

Bizi ilgilendiren her süreç Evrende meydana gelir. Gök cisimlerinin hareketinin etkisini kesinlikle “hissediyor”. Ancak bu etkinin “katı olmayan”, belirleyici olmayan bir etki olduğu ortaya çıkabilir. Bu, özellikle astronomik zamanın belirli aralıklarında sürecin durumunun değişmeden kalmasıyla kendini gösterebilir. Bu bağlamda, daha önce dış dünyadan izole edilmiş, kapalı, boş bir oda örneğini hatırlayalım. Odaya sadece bir canlının uçmasına izin verelim. Birkaç gün boyunca, odanın durumunda değişiklik beklenemeyeceğinden, "oda-sinek" sisteminin durumundaki değişiklikler sineğin hareketlerine bağlı olacaktır. Aynı zamanda bir sineğin davranışının astronomik zamanın akışıyla sıkı sıkıya bağlantılı olduğunu hayal etmek zordur.

Bu kadar uzun bir açıklama yaptıktan sonra sürecin kendi zamanını hesaplamak için kullanılan algoritmayı anlatmaya geçelim.

Bu algoritmada, yerel maksimumları hesaplamak için kullanılan birim, doğal bir zaman ölçüsü olarak seçilir. Ek olarak, daha önce belirtildiği gibi uygun zamanın durduğu, sürecin durağan durumunun olası bölümleri de dikkate alınır. İki durumun özdeşliği yalnızca ölçüm doğruluğu sınırları dahilinde söylenebildiğinden, bundan sonra belirli bir pozitif sayı e kullanılır - izin verilen ölçüm hatası.

Yani, algoritmanın giriş verileri doğal sayı n, pozitif sayı 8, diziler (tk) ve (x k), k = 1, ..., n'dir. Programlama kolaylığı için algoritma şu şekilde sunulmuştur: sıralı olarak yürütülen dört modülden oluşur.

Modül 1, genel durumda p, e, t k), (x k) verilerini kullanarak yeni diziler 7 = (7+ X = (X t) ve çok spesifik bir eşlik eden dizi P = (?) oluşturur, burada 1 = 1, ..., t ve t<Сп. Основное назначение этого модуля -- выявление в массиве x k) последовательностей идентичных состояний процесса, сохранение первых элементов в таких последовательностях и удаление всех остальных и, наконец, уменьшение по определенному, правилу исходного интервала наблюдения от t до на сумму тех промежутков времени, в которых процесс протекает стационарно.

Modül 1 aşağıdaki prosedürleri içerir:

p: = 1, t: = 0, k: = 1.

s. Belirli başlangıç ​​değerlerine sahip 1, 2 sayaç tanıtıldı:

s. 3, 4 sayaç değerleri 1 artar.

k^n durumunu kontrol edin. Tamamlanmışsa 6. adıma, aksi takdirde 11. adıma gidin.

x k --x k = e eşitsizliğini kontrol edin. Tutarlıysa 7. adıma gidin, değilse 9. adıma gidin.

7. tii = ti - (tkl - tk), i = k1, ..., s.

Bu prosedür, hata içerisinde Xk ve Xk 1 değerlerinin birbirinden ayırt edilememesi durumunda tk'den başlayan tüm zaman noktalarının tki-tk miktarı kadar azaltılacağı anlamına gelir.

r = r. 4. noktaya dönün.

TV = tk; Xv:=xk ; p = p v = v+l., yani. T, X, P dizilerinin elemanları oluşturulur ve bir sonraki v değeri atanır.

• 10. (t k, ..., t n VE (Xk, - X n)'yi n-k 1 + 1 boyutunun başlangıç ​​dizileri olarak alın ve ardından adım 2'ye dönün.
• 11. m, (T), (X,) ve (P,)'yi yazdırın, burada i = l, ..., t.Son.

Eşlik eden P dizisinin elemanlarının anlamını açıklayalım. Önceki metinden, pk değerinin, x pi+'dan doğrudan sonra gelen ve ondan farklı olan (xk) dizisinin elemanlarının sayısına eşit olduğu sonucu çıkıyor ... +, + e'den küçük.Ayrıca pi+ ... +p m = n olduğunu da not ediyoruz.

Örnek 1. Verilen: n = 20, (/*) = (2, 4, 7, 10, 12, 13, 15, 17, 20, 22, 24, 25,

• 27, 30, 32, 33, 34, 35, 36) ve (x,)= (4, 4, 6, 6, 6, 3, 2, 4, 3, 3, 3, 2, 2, 4, 5 , 5,
• 5, 4, 3), bkz. 9, a.

Modül 1'in çalıştırılması sonucunda m = 11 elde edilir,

(G) = (2, 3, 4, 6, 8, 11, 1-2, 15, 17, 18, 19); (X,) = (4, 6, 3, 2, 4, 3, 2, 4,5,4,3)

i(d.) = (2, 4, 1, 1, 1.3, 2, 1.3, 1, 1), bkz. şekil. 9, b.

Modül 2. Bunun için giriş verileri bir doğal sayı m'nin yanı sıra (7+ (X L), = 1, ..., m) dizileridir. Dizideki bu modül (TJ, zamanın anlarını tanımlar [TM a], 1 = 1 m (mi)

Örnek 2. m, (Ть) ve (X,] değerleri önceki örnekten alınmıştır.Modül 2'yi tamamladıktan sonra ml = 3, m2 = 8, (Ш,) = (3, 8, 17) elde ederiz. ), (Т*) = (3, 4, 6, 8, 11, 12, 15, 17), ayrıca bkz. Şekil 9, b.

Modül 3. Giriş verileri ml, m2, (TM n), 1 = 1, ..., ml, (G*), /2 = 1, ..., gn2.

Bu modül aşağıdaki formülü kullanarak bir (t(-r) dizisi oluşturmak için tasarlanmıştır.

TV 6 nerede [TMp, TMn+i]

T değişkeni, x değişkenindeki değişimin ürettiği uygun zamandır. Doğal ölçüsü, yerel maksimumları hesaplamak için kullanılan birimdir.

Örnek 3. T 2) için başlangıç ​​verileri ml, m2 ITM ve örnek 2'deki değerlerle aynıdır. Uygun hesaplamalardan sonra Н = (0; 0,2; 0,6; 1; 1,33; 1,78; 2).

Modül 4. M'nin değerleri ile (xk) dizisindeki x elemanları arasında bir yazışma kurarak sonuçların çıktısını oluşturur.

Örnek 4. Örnek 2 ve 3'teki verilere dayanarak aşağıdaki sonuç elde edilir, bkz. şekil. 9, içinde:

t: 0; 0,2; 0,6; 1; 1.33; 1.44;

x: 6; 3; 2; 4; 3T 0 2;

Böylece, dikkate alınan algoritma, astronomik zaman ölçeğinde kaydedilen sürecin durumundaki değişiklikler hakkındaki bilgilere dayanarak sürecin kendi zamanı kavramını geliştirmemize olanak sağlar. Örneğin, yerel minimumların bir dizisini veya yerel maksimumlar ve minimumlardan oluşan karma bir diziyi hesaplamaya dayanan başka algoritmalar kullanabileceğiniz oldukça açıktır. Deneysel verileri işlerken muhtemelen çeşitli seçeneklerin test edilmesi gerekir. Eğer deneyci herhangi bir nedenle belirli uygun zamanlardan birini seçerse ve (t4 ve (xk) dizilerini alırsa) bir sonraki aşamada deneysel noktalara (t*, x) yaklaşık dünya çizgisine yaklaşmak için bazı matematiksel yöntemler kullanmalıdır. x = x(t) süreci.Bu çizgiyi ilk gözlem periyodunun ötesinde tahmin ederek sürecin daha sonraki seyri hakkında tahminlerde bulunabilir.

Önerilen algoritmayı kullanma olasılığını değerlendirmeyi amaçlayan bir hesaplamalı deneyden bahsetmek ilginçtir. Yıllık nehir akışlarına ilişkin veriler deneysel materyal olarak seçilmiştir. Önceki 40 yıl boyunca Vakhsh (Tacikistan). Aynı dönemde, güneş aktivitesinin en yaygın kullanılan integral endeksi olan Wolf sayısının dinamikleri hakkında bilgi alındı. İkincisi, güneş aktivitesi sürecinin uygun zamanını geliştirmenin temelini oluşturdu. Modern zamanlara gelindiğinde nehir harcamalarına ilişkin bilgiler dönüşüme uğradı. Vakhsh ve daha sonra gözlem periyodu sırasında, güneş aktivitesinin uygun zamanının bir fonksiyonu olarak su akışına teorik bir bağımlılık verildi. Ortaya çıkan grafiğin karakteristik bir özelliği, maksimum ve minimum harcamaların neredeyse periyodik davranışıdır. Ancak maliyetler sabit kalmıyor.