Sunum yükleniyor. Lütfen bekleyiniz

Sunum yükleniyor. Lütfen bekleyiniz

1. KONU BAŞLIKLARI  Süreçlere Yönelik Öneriler  Tasarım Geli ş tirmeye Yönelik Öneriler  Niteli ğ i Arttırmak İ çin Pratik Öneriler  Toplantı Kuralları.

Benzer bir sunumlar


... konulu sunumlar: "1. KONU BAŞLIKLARI  Süreçlere Yönelik Öneriler  Tasarım Geli ş tirmeye Yönelik Öneriler  Niteli ğ i Arttırmak İ çin Pratik Öneriler  Toplantı Kuralları."— Sunum transkripti:

1 1

2 KONU BAŞLIKLARI  Süreçlere Yönelik Öneriler  Tasarım Geli ş tirmeye Yönelik Öneriler  Niteli ğ i Arttırmak İ çin Pratik Öneriler  Toplantı Kuralları 2

3  Amacımız, uygulama alanının özelliklerine bağlı olarak büyük projelerde nitelik, maliyet, müşteri memnuniyeti gibi önemli ölçütleri sağlayabilmeniz için pratikte uygulanabilir bir dayanak sağlamaktır. 3

4  Gerek maddi gerekse insan kaynaklarının en uygun şekilde kullanımı çok büyük önem taşır. Bunların hiç biri tek başına yeterli olmayacaktır.  Örneğin: yalnızca çok başarılı insanları bir araya toplayarak projelerin iyi sonlanması beklenemez. 4

5 A.Proje Yönetimi Yazılımın boyut,iş gücü ve takvim kestirimlerinin yapılması. Üst yönetimin onayının alınması sonrasında projenin başlatılması. Proje yöneticisinin resmi olarak atanması. 5

6 Projede tamamlanması gereken iş paketlerinin oluşturulması Proje ekibinde yer almaya aday çalışanların özelliklerinin araştırılması ve belirlenmesi Seçilen personeli proje iş grubuna atayarak proje ekibinin oluşturulması. Proje risklerinin tanımlanması ve izlenmesi. İş paketleri için zaman ve kaynak bilgileri girerek proje takviminin oluşturulması. 6

7 Projenin takvim,maliyet,nitelik açılarından başarımını izlemek için belirli ölçütler seçilmesi ve hedeflerin belirlenmesi. Proje süresince üretilecek düzenleşim öğelerinin(belgeler,modüller) tanımlanması ve izlenmesi Onaylı proje takvimindeki iş paketlerinin proje ekibindeki çalışanlara atanması. 7

8 Personelin proje kapsamında yapılan işler için harcadığı zamanı bildirmesi Geliştirme etkinlikleri sırasında düzenleşim ögelerinde fark edilen yazılım ve belge sorunlarının tanımlanması,belirlenen sorunların yönetim onayıyla düzeltilmesi ve bu düzeltmenin doğrulanması. 8

9 Tanımlanan yazılım birimleri,yapılan testler ve gözden geçirmeler ile ilgili kayıtların tutulması. Projenin süreçlere uygun yürütüldüğünü belirlemek amacıyla denetlenmesi. Proje takviminin, düzenleşim ögelerinin ve diğer proje bileşenlerinin gerektiğinde güncellenmesi. 9

10 B.İnsan Kaynakları Planlaması  Personel yönetimi için bazı önerileri şu şekilde sıralayabiliriz: 1. İyi bir örgütlenme için; a)Yönetim personelinin konumları oluşturulmalıdır. b)Yetki ve sorumluluklar iyi tanımlanmalıdır. c)Bu konumlarda proje boyunca sabit olarak kalacak eleman bulunmalıdır. 10

11 2. Proje personelinin uyumu çok önemlidir. 3. Proje yöneticisi tüm ekibine kendilerini önemli hissettirmeli aynı zamanda da lider olduğunu göstermelidir. 11

12 4. Proje içinde aynı işle uğraşan ekipler 5-7 kişiden oluşmalıdır.Daha fazlası için sorumluluklar ve yetkiler bölünmelidir. 5. Proje yöneticisi planladığı işlere personel ataması yaparken adil olmalıdır 12

13 6. Personele her türlü teknik destek sağlanmalıdır. 7. Çalışmalar personeli yıldırmamalı,karşılıksız fazla mesai yaptırılmamalı ve başarılı personel ödüllendirilmelidir. 8. Proje planları herkes tarafından erişebilir olmalıdır. 9. Projeye yeni katılan personel için proje içi eğitimler uygulanmalıdır. 13

14 10. Projede çalışan personel genel olarak dikkate alınmalı yalnızca o proje düşünülerek öldüresiye çalıştırılmamalıdır. 11. Haberleşme ortamı proje için son derece önemlidir. 12. Proje personelinin yazılım teknolojilerinin değişik alanlarında uzmanlaşmış olması önemlidir. 14

15 3.Maliyet Kestirimi ve Planlama Maliyet ve öz kaynakların etkin bir şekilde kullanılması için şu önerileri sıralayabiliriz: 1. Proje maliyeti ve zaman planlaması deneysel verilerle işe başlamadan kestirilmeye çalışılır. 2. İlk yapılan yazılımla ilgili kestirimler risk olarak görülür.Zamanla yenilenmelidir. 15

16  3. Tüm kestirimler bir maliyet modeli ile doğrulanmalıdır.  4. İşin ayrıştırmasının alt düzeylerinde bulunan her bir iş için maliyet kestirimi yapılmalıdır. 16

17  5. Tüm maliyet kestirimleri ve planlamalar işe başlamadan önce proje yönetimi tarafından onaylanmalıdır.  6. Genel maliyet kestirimi işe başlamadan önce yapılmalıdır.Daha sonra bu projenin başarımı için bir gereç olarak kullanılabilir. 17

18  7. Yazılım maliyet kestirimi geliştiricinin daha önceki deneyimlerini ve uygulama alanında yaygın olan bazı standartları dikkate alarak hesaplanmalıdır.  8. Tüm yazılım maliyetleri proje planındaki ayrıntılı yazılım işlerine göre tanımlanarak hesaplanmalı ve buna göre izlenmelidir. 18

19 4.Metrik Kullanımı   Metrik kullanımına ilişkin önerilerimiz şunlardır:  Her türlü metrik tanımı uygulama alanını ve sınırlarını içerecek şekilde açıklanmalı,sayısal değerlere oturtulmalıdır.  Toplanamayacak verilere dayanan metrikler kullanılmamalıdır.  Tüm projenin yaşam döngüsü boyunca tanımlanan metriklerin tanımlanması, incelenmesi ve gerekli yerlere rapor edilerek geri besleme sağlaması için ekip içinde sorumluluklar tanımlanmalıdır. 19

20  Metrik uygulaması süreklilikle yapılmalıdır.  Proje planı hazırlanırken metriklerden yararlanılmalıdır.  Metrikler geniş kapsamlı olmalıdır.  Toplanan veriler ve değerlendirmeler proje ekibinin rahatlıkla ulaşabildiği güvenli bir platformda saklanmalıdır. 20

21 5.Nitelik Hedeflerinin İzlenmesi Sistem hatalarını geliştirme sürecinin en erken zamanlarında bulabilmek ve giderebilmek için şu önerileri sunuyoruz : 1. Proje yöneticileri hataların en kısa zamanda bulunması ve giderilebilmesi için uygun yöntemler geliştirmelidirler. 2. Denetimler taviz verilemeden uygulanmalıdır. 21

22  3. Uygulamalar sonucunda,sistemde bulunmuş hata sayısı, yakalanamayan hata sayısı,hatayı ortadan kaldırmadaki etkinlik gibi metrikler toplanmalıdır.  4. Müşteri isteklerinin değişmesi nedeniyle değişiklik yapılması gereken durumlarda nitelik hedefleri de tekrar görüşümelidir.  5. Nitelik hedeflerine uygunluk, geliştirme sırasında düzenli olarak müşteriye bildirilmeli,teslim sırasında risk görülen durumlar açıklanmalıdır. 22

23 6.Disiplinin Sa ğ lanması  Hangi sektör olursa olsun etkinliklerde mutlaka belirli bir disiplin oluşturulması gerekir.Bunun için sunulan öneriler:  Proje Yöneticisinin yetkileri en üst düzey otorite tarafından tanımlanmalıdır.  Teknik kararlar yapılan tartışmalar sonucunda kesin olarak verilmelidir. 23

24  Tüm personel işletme yönetiminin koyduğu yönetsel kararlara uymalıdır.  Tüm bu disipline rağmen biraz esneklik her zaman olmalıdır.  Geliştirme ve test ortamında kişisel yazılımlar bulunmamalıdır.  İletişim ortam ve cihazları belirli kurallara göre kullanılmalıdır. 24

25 25

26  Yazılım geliştirme sürecinin başarısı için yazılım isterleri çözümlemenin doğru yapılması son derece önemlidir.  Bir yazılım ne kadar iyi tasarlanırsa ya da geliştirilirse geliştirilsin müşteri (ya da son kullanıcı) ihtiyaçlarını karşılamıyorsa başarılı sayılamaz. 26

27  Yazılım isterlerinin çözümlenmesi aşamasında müşterinin yazılımdan ne beklediği ayrıntılı olarak belirlenir, gereksinimler açığa çıkarılır, yazılım isterleri modellenir ve tanımlanarak tasarım aşamasına geçilir.  Yazılım isterlerinin çözümlenmesi aşaması müşteri ve geliştirme grubu arasında ciddi bir işbirliği gerektirir. 27

28  Çözümleme aşaması bu iş için yeterince deneyime sahip olan kişilerce yapılmalıdır. Bu kişiler çözümleyici ya da gereksinim mühendisi olarak adlandırılır. 1.Problemin Anlaşılması: Bu aşamada problem derinlemesine incelenerek problemin ne olduğu ve çözüm için yazılımın kapsamının ne olacağı belirlenir. Problemi iyi anlamak problemin yarısını çözmek demektir. 28

29 2.Problemin Çözümlenmesi: İlk aşamada toplanan bilgilere göre, sistemi etkileyen giriş/çıkış etkinlikleri ve kısıtlamaları dikkate alınarak yazılım işlevleri tanımlanır. Yazılımın ne yapması gerektiği bu aşamada ortaya konulur. 3.Modelleme: Sistemin çalışma şekli, veri akışı, işlevsellik gibi parametreleri daha iyi anlayabilmek için modeller yaratılır. Bu işlem kağıt üzerinde çizimlerle yapılabileceği gibi prototipler de kullanılabilir. 29

30 4.Belirtim: Bu aşamada kullanıcının sistemi nasıl kullanacağını ortaya koyan taslak bir kullanım kılavuzu hazırlanır.Temel işlevler, kısıtlar, çalışma şekilleri, ara yüzler, başarım ölçütleri, doğrulama ve geçerleme yöntemleri tanımlanır. 5. Gözden Geçirme: Çözümleme aşaması sonunda ortaya çıkan belgeler müşteri ile birlikte gözden geçirilir ve eğer gerekli görülürse güncelleme ya da düzeltmeler yapılır. 30

31 Büyük ölçekli projelerde isterler genellikle birkaç aşamada düşünülür. 1.Düzey 1: Uygulama Alanı İsterleri: Müşteri görüşmeleri, yazılımın kullanılacağı ortamın ve benzer uygulamaların incelenmesi sonucunda temel gereksinimler çıkarılır ve müşterinin onayına sunulur. 31

32 1.Düzey 2: Kullanıcı İsterleri: Bu aşamada sistemi doğrudan kullanacak olan kullanıcıların beklentileri, istekleri alınır, kullanıcı ara yüzleri ve temel bileşenler ortaya konulur. 2.Düzey 3: İşlevsel İsterler: Bu aşamada geliştirilecek sistem bir bütün olarak düşünülerek işletim kuralları ve süreç yönetimi ile ilgili ayrıntılar tam olarak ortaya konulur. 32

33  Sistem isterleri belgesi hazırlanırken aşağıdaki sınıflardan uygun olanlar bu teknik belgeye dahil edilir. • İşlevsel Özellikler: Veri işleme özellikleri, işlem hızı ve kapasitesi, hatayla baş edebilme gibi. • Güvenlik: Kesintisiz kullanabilme, erişim güvenliği, veri güvenliği gibi. 33

34 • Kullanım kolaylığı: Kullanıcı dostu ara yüzler, öğrenme kolaylığı, uygun kullanım kılavuzları gibi. • Diğer yazılımlar ile iletişim, • Bakım kolaylığı, taşınabilirlik, • Teknik belgeleme, veri yedekleme ve kurtarma, • Geliştirme dili ve platformu, • Uygunluk: Teknik şartnameler, standartlar, yasa ve yönetmelikler gibi. 34

35 35

36  Tasarım sürecinin tüm etkinlikleri Yazılım Geliştirme Planı’nda belirtilen yöntemlere göre yapılmalıdır.  Ortaya çıkan ürünün özelliklerinin doğrulanması için testler yapılması tasarım standartlarının bir parçası olarak değerlendirilmelidir. İzlenebilirlik, tasarım, gerçekleştirim ve test sırasında devam ettirilebilmelidir.  Her türlü tasarım düzenleşim yönetim sistemine girmeden önce yapısal bir incelemeden geçirilmelidir. 36

37  Artımlı geliştirme modeli kullanıldığı taktirde tasarım da artımlı olarak yapılabilir. Ancak düzenleşim yönetim sisteminin bu yapıya uygun destek vermesi gereklidir.  Var olan yazılımın tekrar kullanımı planlandığı taktirde sistem ve yazılım mimarisi tasarımı uygun şekilde yapılmalıdır.  Sistem ve yazılım mimarileri üzerinde Yazılım Geliştirme Planı’nda belirtildiği şekilde doğrulama işlemi uygulanmalıdı r. 37

38 Tasarımcıya Kendi Deneyimlerini Geliştirmesi İçin Öneriler • 1. Yapmak istediğiniz şeyin ne olduğunu önceden tam olarak belirleyiniz. • 2. Amaçlarınız açık ve somut olmasına dikkat edin. • 3. Sosyolojik problemlere teknolojik açıdan yaklaşmayınız. • 4. Var olan sistemlerden esinlenerek başlangıç noktası oluşturacak bir model belirleyiniz. • 5. Tasarımı esneklik, geliştirme, taşıma ve tekrar kullanım özelliklerini karşılaştırabilecek şekilde yapın. 38

39 •6. Tekrar kullanım yazılım parçalarını belgeleri ile birlikte kullanıma sunulacak şekilde hazırlayın. •7. Ayrıntılı düşünme çabalarınızı tüm yazılımın değil de onu oluşturan yazılım birimlerinin tasarımı üzerine yoğunlaştırın. •8. Bir arayüzün başka arayüzlere bağlılığını en aza indirin. •9. Arayüzleri, gereksinimi karşılamaya yetecek en az miktarda bilgi sağlayacak şekilde sağlayın. 39

40 •10. Tasarımı ve sonra da gerçekleştirimi tekrar tekrar gözden geçirip gerekli gördüğünüz düzenlemeleri yapın. •11. Tasarımı ve gerçekleştirimi test edip sonuçlarını değerlendirebilecek yazılım geliştirme yardımcı araçlar kullanın. •12. Her şeyi olabildiğince basit halde ve küçük boyutta tutun. 40

41 •13. Tasarımcıların, kodlayıcıların ve kullanıcıların da birer insan olduklarını ve her zaman hata yapabileceklerini unutmayın. •14. Kullanıcıların her zaman bir mühendis kadar dikkatli ve bilgili olmayacağını düşünerek insan- makine arayüzlerinin uygunluğuna ve sistemin sağlamlığına gerekli önemi verin. •15. Çevrenize tasarımın, kütüphanelerin ve soyut veri tiplerinin tekrar kullanımı fikrini yayın ve bu fikri somut örneklerle deste kleyin. 41

42 TEKRAR KULLANIM 1.Tekrar kullanım esasları Yazılım Geliştirme Planı’nda yer almalıdır. 2.Tekrar kullanılacak ürünler, önce proje isterlerine göre kendi başlarına test edilmelidir. 3.Tekrar kullanıma esas olacak öğeler, hazır ticari ürünler ve özel üretilmiş birimler gibi geliştirme sürecinde üretilmeyecek yazılımlar birer risk unsuru olarak ele alınmalıdır. 4.Geliştirme süreci dışında temin edilecek öğelerin tekrar kullanımı ancak bu tür öğelerin özel bir denetim sonucu kabul edilmesinden sonra yapılmalıdır. 42

43 5.Bu tür öğelerin kullanıma karar verebilmek için tüm yaşam boyunca gerekecek bakım maliyeti, üst sürümlere yükseltme, garanti, lisans ve diğer öğelerle olan uyumluluk hususları dikkate alınmalıdır. 6.Bu tür öğelerin kullanımı için verilecek karar mimari ve tasarım tanımlamaları ile müşteri isteklerine uygun olmalıdır. 7.Sistemin yaşam çevrimi boyunca hazır olarak kullanılacak kritik öğelerin sorunsuzca kullanılabilmesi için gerekli çalıştırma lisansları, bakım ve destek olanakları ile mümkünse kaynak kod ve geliştirme lisanslarının temin edilmesi, bunların şimdiki ve gelecekti maliyetleri konusunda kestirimlerde bulunularak geliştirici ve müşteri arasında bire bir anlaşmaya varılmalıdır. 43

44 İSTEKLERİN VE TASARIMIN DENETLENMESİ  Geliştirilen yazılım ürünleri düzgün iletişim yönetim sistemi altına alınmadan önce resmi bir test ve denetimden geçirilmelidir. Bundan sonra bu ürünler başka ürünlerin geliştirmelerinde temel alınırlar.  Denetim, yazılım geliştirme planında belirtildiği şekilde, o ürün için geçerli olabilecek kabul esaslarına dayalı bir süreci şeklinde yapılmalıdır. 44

45  Denetim sırasında belirli bir takım metrikler toplanmalı ve izlenmelidir. Bu metrikler arasında, yazılım kusurları, kusurların bulunduğu yerler, bu kusurları gidermek için gerekli gayretler ve denetim için harcanan öz kaynakların miktarı bulunabilir.  Denetimler, kavram tanımlamasıyla başlar, mühendislik etkinliklerinin tamamlanmasıyla son bulur.  Program veya proje için ayrılan mali kaynaklar denetim ve sorun giderme için gerekli harcamaları da içermelidir. 45

46  Denetimlerin başarılı sonuçlanması ürünün veya tanımlanmış işin resmi bitişini göstermelidir.  Denetim ve gözden geçirme süreci ürünün tanımlanması ve ilk isterlerinin belirlenmesi ile başlar, mimari, tasarım, kodlama, tümleştirme, test ve belgelendirme aşamalarında devam eder. 46

47 GERÇEKLEŞTİRİM  Yordamlarınızı 20 satır fazla uzatmamaya çalışınız.  Bir kod dosyasının çok fazla uzamamasına gayret gösterin.  Büyük dosyalar yerine modüler bir dosya yapısı oluşturun.  Kod yazarken küçük ve mantıklı bölümler halinde yazıp sık sık derleme yapın. 47

48  Kullanılan bilgisayar mimarisinin özelliklerini dikkate alın.  Kod içerisinde sıkça kullandığınız sayı değerlerini sabit değerler olarak yazılımın tümü tarafından erişilebilecek bir yerde tasarlayın.  Yordamlara parametre geçirirken mümkün olan yerlerde nesnelerin adreslerini kullanın. 48

49  Kodlama da kullanılan programlama dili desteklese dahi ‘go to ‘deyimi kullanmayınız.  Mümkün oldukça açıklama satırı kullanınız.  Metinin şekilsel düzenine dikkat edin.  Kodlamada ilerlerken yazdıklarınızı sık sık değişik ortamlarda yedekleyiniz. 49

50  Dizin isimlerini mantıklı ve disiplinli bir şekilde oluşturunuz.  Yazılımı denetlerken hata oluştuğunda hemen donanım hatası olması yerine yazılımımızdaki mantık hatası arayınız.  Hiçbir zaman hatalara teslim olmayın. Hiçbir yazılım geliştirici hata ayıklama işleminden kaçamaz.  KOD YAZMAK BİR SANATTIR. 50

51 SÜREKLİ TEST 1)Kritik bileşenler saydam kutu yöntemiyle test edilmelidir. 2) Her türlü test işlemi önceden üzerinde karar kılınmış ilkelere göre yapılmalı ve belirli bir plan izlenmelidir. Bu amaç için gerekli olan harcamalar önceden bütçelendirilmelidir. 3)Düzenleşim yönetim sistemi altına alınıp sabitlenecek her ürün ya da her öğe mutlaka bir test sürecinden geçirilmelidir. 51

52 4) Testler yalnızca ortalama sistem durumlarını değil, aynı zamanda anormal ve arıza durumlarını, aşırı yüklemeleri de içermelidir. 5) Test için kullanılacak her türlü araç ve gereç, test durumları, senaryolar, kabul koşulları, beklenen değerler denetim altına alınmalı ve düzenleşim yönetim sistemi altında tutulmalıdır. 6) Her test için giriş ve çıkış değerleri, izlenecek yollar ve kabul esasları tanımlanmalı, sonunda “geçti” veya “kaldı” gibi bir değerlendirme yapılmalıdır. 52

53 7) Test planı belirli amaçlar içermelidir. Üretilen ve hazır olarak kullanılan öğelerle oluşturulan sistemin doğru çalıştığının gösterilmesi en büyük amaç olmalı, bu gerçekleştikten sonra ürün kullanıma sürülmelidir. 8) Test işlemlerinin olabildiğince kendiliğinden yapılması, çıkan hataların ivedi olarak düzeltilip tekrar test yapılabilmesini sağlar. Bu test çevrimi ne kadar hızlı olursa testler için kullanılması gereken toplam süre de o kadar düşer. 53

54 SIK DERLEME VE TEST  Ana sistem testleri tamamlandıktan sonra hedef sistem testleri olabildiğince kısa sürede yapılmalıdır. Bu şekilde, sık derleme ve üretme kullanılarak olası hataların daha çabuk bulunması sağlanır.  Test sistemi üzerinde en küçük yazılım yapısı oluşur oluşmaz testlere başlanmalıdır. Bu maksatla kullanılacak yazılımlar sık sık derlenip üretilmelidir. 54

55  Test için kullanılacak tüm yazılımlar düzenleşim yönetim sisteminden alınarak kurulmalıdır. Yeni bir sürüm ortaya çıkmışsa başka bileşenlerin testlerinde kullanılmadan önce bu yeni sürüm testlerden geçirilmelidir.  Eklenen bir özellik veya tümleştirilen bir bileşen için gerekli testler ancak ana sistemin sabitlenmesi ve testlerinin başarılı olmasından yapılmalıdır.  Testler sırasında bulunan tüm kusurlar tanımlanmalı ve belgelendirilmelidir. Aksi durumda, bir sonraki testlerde yine aynı kusurların tekrarlanmasından kaçınılmaz. 55

56  Testlerin sonuçları tüm proje personeline açık olmalı, hatta sıkça sorulan sorular belirli bir yerde toplanmalı ve bilgiler başkaları ile paylaşılmalıdır.  Asıl kullanılacak sisteme en yakın bir sistem düzeneği, alt sistemler veya onların benzeticileri (simülatör) geliştirme yapılan yerde kurularak testlerin olabildiğince gerçekçi ortamda yapılması sağlanmalıdır. 56

57 HATA AYIKLAMA o Test aşaması için kapsamlı test senaryoları hazırlanmalı ve her senaryo mutlaka sonuna kadar çalıştırılmalıdır. Bu şekilde, olası yazılım kusurlarının varlığının belirlenmesine çalışılmalı, kusur belirlendikten sonra temizleme aşamasına geçilmelidir. o Testler kötümser bir yaklaşımla yapılmalıdır ki kusurlar ortaya çıksın. Yakalanan her kusur ileride olası bir yazılım hatasına engel olacaktır. 57

58 o Hata ayıklama sırasında yeri belirlenen yazılım kusurunun giderilmesi sırasında yeni bir kusur katılması yüksek bir olasılıktır. Bu nedenle, kusurlar birer birer ele alınmalı, çok fazla değişiklik yaparak birden fazla kusuru bir defada gidermeye çalışılmamalıdır. o Çoklu programlama ortamlarında hata ayıklama son derece güçtür. Bu tür ortamlar tasarlanırken, modüllerin ayrı ayrı test edilebilmelerine olanak tanınması çok önemlidir. 58

59 o Birden fazla modülde hata bulunması durumunda kusurlar bir sıraya göre düzeltilmeli, birden fazla modül bir anda değiştirilmemelidir. o Kodlama sırasında, her bir yordam içine hata yakalama tuzakları yerleştirilmeli, yakalanan hatalar nedenleriyle birlikte standart bir hata raporlama düzeneğine bildirmelidir. Bu şekilde, yürütme sırasında oluşan bir hataya neyin neden olduğunu ve ne zaman oluştuğunu bulmak kolaylaşı r. 59

60 o Dağıtık ortamlarda, yazılımda meydana gelen bir hatayı bulmak için hangi düğümde hangi modüllerin çalıştığının takip edilmesi gereklidir. Bu tür ortamlarda, küçük ölçekli de olsa mutlaka bir ara katman kullanılmalı, kodlama, hata yakalama ve raporlamada belirli düzenekler bulunmalıdır. o Testler sürerken hata düzeltme işlemi sürdürülmemelidir. Her hata durumunda da testi durdurup hatayı düzeltmek, sonra teste kaldığı yerden devam etmek de her zaman doğru değildir. Eğer testlerin gidişini etkileyecek derecede büyük hata varsa, test durdurulmalı, ileriki bir tarihte tekrar edilmelidir. 60

61 ÖLÇME SÜRECİ UYGULAMASI ÖLÇME SÜRECİ UYGULAMASI 1.Örgüt içindeki herkesin ölçme sürecinin yeteneklerini ve kısıtlarını anlaması sağlanmalıdır. 2.Metriklerin bir anlam ifade edebilmesi için herkesin ölçülen verilerin ne anlama geldiği hakkında aynı düşünceye sahip olması gereklidir. 3.Önce küçük hedeflerle işe başlanmalı, yalnızca birkaç temel ölçüm kullanılmalı ve etkileri kontrol edilmelidir. 61

62 4.Yalnızca tanımlanan ve kullanılacak olan metrikler toplanmalı, veriler kullanılmayacaksa boşuna toplanmamalıdır. 5.Ölçme için bir kişi görevlendirilmeli, metrikleri doğru şekilde toplaması ve birleştirmesi için geliştiricilerle yakın temasta olması sağlanmalıdır. 62

63 6. Metrik toplamak ve sağlamak için basit de olsa bir araç kullanılmalıdır. 7. Ölçümlere dayanarak belirli bir grubu ya da kişiyi değerlendirme yoluna gidilmemeli, kimsenin de böyle düşünmesine izin verilmemelidir. 8. Ölçüm sonuçları iyi ya da kötü olsun, mutlaka raporlanmalıdır. 63

64 64

65 Bu kısımda bir yazılım ürünün genel niteliğini arttırmak için izlenmesi yararlı olan bazı önerilerde bulunmaktayız. •İŞLEVSEL NİTELİK  İşlevlerin tutarlılığı ve doğru uygulanması isterler çözümlemesi aşamasından başlayarak yönetilmelidir.  Ürün mümkünse ayrı işlevlere sahip, ayrı bileşenler halinde geliştirilmeli ve her bileşen ayrı bir ürün gibi kabul edilerek kullanıcı memnuniyeti ölçülmelidir. 65

66  İşlevler karmaşıklıklarına göre sınıflandırılmalı ve kullanıcıya yapılan sunumlarda bu sınıflandırmaya dikkat edilmelidir.  Yazılımın sahip olması gereken tüm işlevlerin yerine getirildiğini kanıtlamak üzere doğrulama ve geçerleme etkinlikleri uygulanmalıdır. 66

67  Veri ve işlev arasındaki ilişkilerin kullanıcılar açısından belirgin olmasına önem verilmeli, doğru işlevlerle hatalı verilerin ayrışımı kolayca sağlanmalıdır.  Bir akış izleyen işlevler ayrıştırılmalı ve kullanıcının bu akışı bilmesi, izlemesi ve kabul testleri sırasındaki senaryoları anlaması sağlanmalıdır.  İlk örnekler kullanıcının ön değerlendirmesinden geçirilmeli düzeltme istekleri dikkate alınmalı, ürün teslimi alınan geri beslemelerden sonra yapılmalıdır. 67

68 GÜVENİLİRLİK 1.Yazılım ürününün kesintisiz çalışabilme özelliği, kullanıcıya teslim etmeden önce yapılan denenmelerle, kullanıcının gözetiminde izlenerek belirlenmelidir. 2.Geliştirme sırasında yapılan denemelerde, aynı ortamda olabildiğince çok ve değişik yazılım ve donanım bileşeninin beraber çalışabildiği gözlemlenmelidir. Bu amaçla gerekirse tanımlı sistem yapılanması dışında testler uygulanmalıdır. 68

69 3.Üründen kaynaklanmayan kısıtlayıcı koşullar test ortamında oluşturulup ürün davranışları yakından izlenmelidir. 4.Ürünün güvenilirliğini etkileyecek bilgisayar mimarisi, işletim sistemi, veritabanı gibi ortam koşulları sistemde kullanılacak diğer bileşenlerin üreticileriyle ortak çalışılarak belirlenmelidir. 69

70 BAKIM KOLAYLIĞI  Ürün bileşenlerinin bakım kapsamında yer alacak değişiklikleri sorunsuz içerebilmeleri için tasarımda ekler yapılmalı, esnek tasarımlar geliştirilmelidir.  Tasarım sırasında, problemin yalnızca bugünkü şeklini çözmeye değil, gelecekteki gereksinimlerini de karşılamak hedeflenmelidir. 70

71  Üründe oluşabilecek temel sorunlar önceden tanımlanmalı, bir sorunla karşılaşıldığında o anda olası düzeltme yöntemleri kullanıcıya sunulmalıdır. Bakım için gerekli temel etkinlikler belgelenmeli, süreçler tanımlanmalıdır.  Bakımdan sorumlu personel, değişikliklerin uyarlanabilmesi için eğitilmelidir. 71

72 72

73  Pek çok işyerinde çalışma grubu büyüdükçe eşgüdümü ve bilgi paylaşımını sağlamak amacıyla toplantı yapılır.Bazen bu toplantılar o kadar çok ve uzun olur ki asıl işi yapmaya zaman kalmaz. 73

74  Kötü yönetilen,kötü planlanan,iyi hazırlanılmamış toplantılar insan kaynağının önemli miktarda zaman dilimini yok eder.O nedenle evrensel nitelikte olan toplantı kurallarını incelemekte yarar vardır. 74

75 a.Toplantı Verimi  Toplantıların verimli geçmesi ve amacına ulaşması için birkaç ilke sıralanabilir: Toplantı Duyurusu:  Toplantıların başarıya ulaşabilmesi ve amacına uygun sonlanabilmesi için katılımcılara önceden toplantıların gündemi ile ilgili bilgi verilmesi gerekir. Katılımcıların hazırlanması için gerekli süre mutlaka göz önüne alınmalı,toplantının yapılacağı yer,tarih ve saat bilgileri ile süresi de kesintisiz olarak bildirilmelidir. 75

76 Toplantı Zamanı: o Katılımcıların istekliliğini etkileyecek önemli bir unsur da toplantı zamanıdır.Yemek veya mola saati öncesi,mesai bitimine yakın veya bir tatil arifesinde planlanan toplantıların verimsiz geçme olasılığı yüksektir. 76

77 Toplantı Lideri:  Bir toplantı mutlaka bir kişinin liderliğinde yürütülmeli ve bunuda bütün katılımcılar önceden bilmelidirler.Genelde önerilen,toplantıyı düzenleyen kişinin toplantı liderliğini üstlenmesidir.  Toplantı liderinin amacı,konuşmaları gündem maddeleri üzerinde yoğunlaştırmaya çalışmak ve sonuç almaktır.Toplantı kayıtlarını tutmak üzere de bir kişi görev almalıdır. 77

78 Toplantı Ortamının Hazır Olması: • Toplantıdan önce,toplantı sırasında gerekli olacak araç gerecin hazırlanması ve denetimini önemlidir.Düzgün ve büyük bir masa,yeteri kadar sandalye,çalışır durumda ve ayarları tam olarak yapılmış yansı makinesi,çizim tahtası ve yazı malzemeleri,taşınabilir bilgisayarlar için elektrik prizleri ve ağ bağlantıları bu gereçlerden bazılarıdır. 78

79 • Hazırlığı yapılmamış bir toplantı salonu,toplantının geç başlamasına veya gereksiz yere bölünmesine neden olabilir.Çok önemli ve süre kısııı olan toplantılardaa kritik gereçlerin bir yedeğinin hazırda tutulması,hatta yedek güç kaynağının hazır bulunddurulması yararlı olur. 79

80 Zamanında Başlama: •Toplantılara mutlaka bildirilen zamanda başlanılmalıdır.Katılımcıların zamanlamaya gerekli özeni göstermeleri bir kültür ve disipilin unsuru olmasına rağmen gerekirse bu konudaa önceden uyarı yapılmalıdır. 80

81 •Toplantı yöneticisi,zamanında toplantıyı başlatmalı ve geç kalaanlara ayrı bir açıklama yapmak üzere toplantıyı bölmemelidir.Bu konudaki ciddiyet,katılımcıların da toplantıya tam zamanında gelme konusunda hassasiyet göstermelerine neden olur. 81

82 Toplantının Bölünmemesi: • Toplantı sırasında yapılan yiyecek ve içecek servisleri, telefon görüşmeleri,dışarı çağrılmalar, imza almaya gelenler katılımcıların dikkatini dağıtır.Bu tür gereksinimler bir saatten fazla sürecek toplantılarda düzenli aralar verilerek toplantı salonunun dışında gerçekleştirilmelidir. 82

83 Toplantı Amaçlarının Korunması: •Toplantı sırasında karşılaştırılan en büyük sorunun “konudan sapma” olduğu belirlenmiştir.Toplantı liderinin ve katılımcıların toplantı gündemine sadık kalması ve problemin özüne yönelik tartışmaların yapılması önemlidir. Akışı denetim altında tutulmayan toplantılarda problemlerin etrafında dönülür,kişisel düşünceler açıklanır,fakat hiçbir zaman öze inilemez. 83

84 Toplantının Başarısı: •Toplantının başarılı olması katılımcıların arasında düşüncelerin ve bilgilerin açnıkça dolaşmasına bağlıdır.Katılımcılar,kişisel çatışmalarından veya ast-üst bürokrasisinden kaçınmalı,problemlere odaklanmalıdırlar.Toplantının hedeflerine ulaşıldığında,kilit noktalar,önemli görev,sorumluluk ve yetki atamaları tamamlandığında, bir özetleme yapılmalı ve toplantıya ilişkin belgelerin dağıtımı hakkında bilgi verilmelidir. 84

85 Toplantının Sonlandırılması: •Toplantı lideri toplantıyı önceden duyurulan saatte bitirmeye özen göstermelidir.Eğer tartışma konuları henüz bitmemiş ise, ya tüm katılımcıların onayıyla ugun bir süre uzatılmasına gidilmeli ya da yine ortak olarak belirlenecek başka bir tarih ve saatte buluşma düzenlenmelidir. 85

86 Toplantı Belgeleri: •Tutanaklar, toplantıda yapılan konuşmaların ve alınan kararların saptanmasını sağlar. Ancak tutanak, konuşulan her kelimenin tespiti demek değildir. Tutanaklarda, yapılan konuşmalar özlü bir şekilde yazılır. Sonra sonuç ve öneriler dikkatle not edilir. Çok önemli toplantılarda söylenenlerin aynen tespiti gerekebilir. 86

87 •Bu durumda toplantıdan önce tutanağı tutacaklara bilgi verilmelidir. Tutanağı, eğer varsa stenografın tutması ya da elektronik kayda alınması uygun olur. Tutanaklar sık sık başvurulan kaynaklar olduğundan, kayıtların açık, doğru ve eksiksiz olmasına dikkat edilmelidir. 87

88 •Toplantı Tutanağı aşağıdaki kısımlardan oluşur.  Tanım: •Proje adı,toplantı gündemi,ilgili girdiler,tarih,zaman,yer,süre.  Katılımcılar: •Her katılımcının adı,bulunduğu bölüm ve görevi,telefon numarası,e-posta adresi,imzası. 88

89  Denetim: •Toplantıya katılan taraflardan yetkili kişilerin imzaları.  Görüşülen Konular: •Toplantıda görüşülen konular,kişilerin kayıt altına alınması gereken önemli ifadeleri,alınan kararlar.  Eylem Maddeleri: •Belirli bir sıra numarası ile bir sonuca bağlanması gereken eylem maddeleri, her bir maddenin sorumlusu, planlanan bitiş tarihi. 89

90  HAZIRLAYANLAR  MEVLÜT İ NAN 90


"1. KONU BAŞLIKLARI  Süreçlere Yönelik Öneriler  Tasarım Geli ş tirmeye Yönelik Öneriler  Niteli ğ i Arttırmak İ çin Pratik Öneriler  Toplantı Kuralları." indir ppt

Benzer bir sunumlar


Google Reklamları