Sözleşmeyi ya da başka bir zorunlu spesifikasyonu sağlamak için geliştirilen ürün, hizmet ya da sonuçtan beklenen şart ya da yetenek.
Örnekler:
İnternet üzerinden kitap satış sitesinin sözleşmesinin maddelerinden biri:
İnternet sitesi IE 9+ ve Firefox12+ tarayıcılarında çalışacaktır.
Zorunlu spesifikasyonu sağlama örneği:
Bir yazılım şirketinin ihaleye girme şartlarından biri olan bilgi güvenliğini sağlama derecesini göstermesi için ISO 27001 sertifikasyonu alma gerekliliği
28 Temmuz 2013 Pazar
3 Mayıs 2013 Cuma
CMMI ile İlgili Bilin(mey)en Yanlışlar-I
CMMI ile ilgili işlere oldukça emek ve zaman harcamış biri olarak konu ilgili bir takım yanlış anlamaların var olduğunu belirtmek isterim. Bu yazıyı da bu yanlış anlamalara elimden geldiğince açıklık getirmeye çalışacağım.
Yazımın başlığına dikkatinizi çekmek istiyorum: "CMMI ile İlgili Bilin(meyen)en Yanlışlar". Aslında amaç şu; yanlış olduğu bilinseydi, yapılmazdı :)
CMMI konusunda şanslı bir insan sayıyorum kendimi. Bir kere, her zaman uygulayan tarafında yer almış olmam en büyük şansım. Modeli sadece okuyarak, varsayarak, hayal ederek öğrenmedim. Şirketin kendi çalışma biçimi ile süreç alanları ile ilişki kurarak, yapılması gerekenleri değil yapılan ile yapılması gereken arasındaki ayrışmayı bularak, açıkcası bizzat yaşayarak uygulamak benim en büyük kazancım oldu.
Model zaten kendisini uyarlamanızı (tailoring) istiyor. Bu uyarlamayı yapabilen şirketlerin başarılı olduğunu özellikle belirtmek isterim. Bazılarını, modeli uygulamaya çalışanları mankenin üstünde iyi duran bir elbiseyi, kendi üstlerinde de aynı şekilde durduğunu zannedip gülünç duruma düşen ergenlere benzetiyorum. Eğreti durur model üstlerinde.
Her yazılım şirketi temelde aynı işleri yapar, bu kesinlikle doğrudur. Bununla birlikte uygulamaları aynı olmayabilir. Kritik sistem üretilirken gösterilen özen ile okul projesini gerçeklememiz aynı değildir.
Ancak, şirketler neye önem verdiklerine karar vermeleri gerekir. Anahtar süreçlerine kritik sistem geliştiriyormuşcasına önem ve özen göstermelidirler. Bazı uygulamaları okul projesi kıvamında da olabilir.
Karar vermek en önemli anahtar sürevinizdir bence. Bir takım kararlara dayanarak şirket uygulamalarınızı ne kadar olgunlukta yapacağınız belirginleşir. Aslında bunu yaparken CMMI'ın hangi olgunluk seviyesine ulaşmak istediğiniz ortaya çıkarırsınız ve bir planınız olur elinizde. Planınız varsa işe başlamak için bir sayanağınız var demektir.
Hap Çözüm Kıssadan Hissesi: Herkesin CMMI'ı kendine
***Bu konu devam eder***
Yazımın başlığına dikkatinizi çekmek istiyorum: "CMMI ile İlgili Bilin(meyen)en Yanlışlar". Aslında amaç şu; yanlış olduğu bilinseydi, yapılmazdı :)
CMMI konusunda şanslı bir insan sayıyorum kendimi. Bir kere, her zaman uygulayan tarafında yer almış olmam en büyük şansım. Modeli sadece okuyarak, varsayarak, hayal ederek öğrenmedim. Şirketin kendi çalışma biçimi ile süreç alanları ile ilişki kurarak, yapılması gerekenleri değil yapılan ile yapılması gereken arasındaki ayrışmayı bularak, açıkcası bizzat yaşayarak uygulamak benim en büyük kazancım oldu.
Model zaten kendisini uyarlamanızı (tailoring) istiyor. Bu uyarlamayı yapabilen şirketlerin başarılı olduğunu özellikle belirtmek isterim. Bazılarını, modeli uygulamaya çalışanları mankenin üstünde iyi duran bir elbiseyi, kendi üstlerinde de aynı şekilde durduğunu zannedip gülünç duruma düşen ergenlere benzetiyorum. Eğreti durur model üstlerinde.
Her yazılım şirketi temelde aynı işleri yapar, bu kesinlikle doğrudur. Bununla birlikte uygulamaları aynı olmayabilir. Kritik sistem üretilirken gösterilen özen ile okul projesini gerçeklememiz aynı değildir.
Ancak, şirketler neye önem verdiklerine karar vermeleri gerekir. Anahtar süreçlerine kritik sistem geliştiriyormuşcasına önem ve özen göstermelidirler. Bazı uygulamaları okul projesi kıvamında da olabilir.
Karar vermek en önemli anahtar sürevinizdir bence. Bir takım kararlara dayanarak şirket uygulamalarınızı ne kadar olgunlukta yapacağınız belirginleşir. Aslında bunu yaparken CMMI'ın hangi olgunluk seviyesine ulaşmak istediğiniz ortaya çıkarırsınız ve bir planınız olur elinizde. Planınız varsa işe başlamak için bir sayanağınız var demektir.
Hap Çözüm Kıssadan Hissesi: Herkesin CMMI'ı kendine
***Bu konu devam eder***
9 Nisan 2013 Salı
Proje Süreçleri
Proje Yönetimi bilgi birikimi, yetenek, ilgili araç ve tekniklerin birlikte kullanılarak doğru şekilde uygulanması ve projenin beklentileri karşılaması için yapılan etkinliklerin bütünüdür.
Beş (5) ana Süreç Grubu vardır:
Beş (5) ana Süreç Grubu vardır:
- Başlatma
- Planlama
- Yürütme
- İzleme ve Kontrol
- Kapanış
Bu beş ana süreç içerisinde en az aşağıda belirtilenleri de içerir ki daha fazlasını yapmanızı da destekler. Ben bu maddeleri CMMI'da Proje Yönetimi süreç alanlarıile de çapraz ilgisinin de olduğunu belirtmek istiyorum. Bu yüzden ilgili CMMI Süreç Alanı ve seviyesi ile birlikte gösteriyorum:
- Gereksinim tanımlama --> Gereksinimlerin Yönetimi (PM-REQM-L2)
- Paydaşların beklenti ve ihtiyaçlarına proje planlama ve yürütme etkinliklerinde hitap etmek --> Proje Planlama (PM-PP-L2)
- Paydaşlar arasında iletişimi etkin, etkili ve işbirliği kurmak, sürdürmek ve yürütmek -- Entegre Proje Yönetimi (PM-IPM-L3)
- Proje gereksinimlerini karşılarken ve proje ürünlerini oluştururken paydaş yönetimini gerçekleştirmek (PM-IPM-L3)
- Aşağıda verilen proje kısıtları arasında denge oluşturmak
- Kapsam --> Entegre Proje Yönetimi (PM-IPM-L3)
- Kalite --> Süreç ve Ürün Kalite Güvence (SP-PPQA-L2)
- Takvim --> Proje Planlama (PM-PP-L2)
- Bütçe --> Entegre Proje Yönetimi (PM-IPM-L3)
- Kaynaklar ve --> Entegre Proje Yönetimi (PM-IPM-L3)
- Riskler -- Risk Yönetimi (PM-RM-L3)
Beş ana süreci yazılım projesinde ister şelale gibi akıtırsınız ister V modelini kullanırsınız ya da agile yaklaşımınıza izlenecek yol haline getirirebilrsiniz. Yukarıda noktalı verilen maddeleri de seçtiğiniz yazılım geliştirme modeline uygun olarak yedirebilirsiniz.
7 Nisan 2013 Pazar
Örnek Olay
Önek olay'ın derli toplu toplam hali burada olacak:
NextGen firması yabancı bir firmanın açtığı ihaleye katılmak istemektedir. İhalenin ön koşullarından bir tanesi ISO/IEC 27001 ISMS (Information Security Management Standard) sertifikasyonuna sahip olmaktır. Firma bu belgeye sahip değildir. İhale son başvuru tarihi 22. Aralık. 2013'tür.
Firma ISO/IEC 27001 ISMS sertifikalandırması için bir proje başlatacaktır.
Başlangıç tarihi: 8. Nisan. 2013
Bitiş tarihi: 8. Aralık. 2013
Çıktı: ISO/IEC 27001 ISMS sertifikası
Proje Nedir?
PMBOK 5. sürüme göre:
Benzersiz bir ürünü ya da hizmeti ya da sonucu ortaya çıkarmak için geçici olarak üstlenilen yoğun etkinliklere proje denir.
Başlangıcı ve bitişi bellidir. Sonuca ulaşamaması ya da iptal edilmesi proje olarak tanımını etkilemez.
Geçici süresi ile ilişkili değildir.
Bir işin bir kere yapılmasıdır.
Projenin belli başlı özellikleri:
Örnek Olay:
NextGen firması yabancı bir firmanın açtığı ihaleye katılmak istemektedir. İhalenin ön koşullarından bir tanesi ISO/IEC 27001 ISMS (Information Security Management Standard) sertifikasyonuna sahip olmaktır. Firma bu belgeye sahip değildir. İhale son başvuru tarihi 22. Aralık. 2013'tür.
Firma ISO/IEC 27001 ISMS sertifikalandırması için bir proje başlatacaktır.
Başlangıç tarihi: 8. Nisan. 2013
Bitiş tarihi: 8. Aralık. 2013
Çıktı: ISO/IEC 27001 ISMS sertifikası
Benzersiz bir ürünü ya da hizmeti ya da sonucu ortaya çıkarmak için geçici olarak üstlenilen yoğun etkinliklere proje denir.
Başlangıcı ve bitişi bellidir. Sonuca ulaşamaması ya da iptal edilmesi proje olarak tanımını etkilemez.
Geçici süresi ile ilişkili değildir.
Bir işin bir kere yapılmasıdır.
Projenin belli başlı özellikleri:
- Yeni bir ürün ya da hizmet ya da sonuç geliştirmek
- Organizasyonun yapısınıl, süreçlerinil, istihdamını ya da şeklinde bir değişikliğe etki etmesi
- Yeni ya da güncellenen yazılım ya da donanım içeren bilgi sistemi geliştirme ya da satın alma
- Araştırma etkinliği içeren
- Bir bina, fabrika ya da altyapı inşa eden ya da
- İş süreçleri ve ordamları (prosedürleri) uygulama, iyileştirme ya da zenginleştirme
Örnek Olay:
NextGen firması yabancı bir firmanın açtığı ihaleye katılmak istemektedir. İhalenin ön koşullarından bir tanesi ISO/IEC 27001 ISMS (Information Security Management Standard) sertifikasyonuna sahip olmaktır. Firma bu belgeye sahip değildir. İhale son başvuru tarihi 22. Aralık. 2013'tür.
Firma ISO/IEC 27001 ISMS sertifikalandırması için bir proje başlatacaktır.
Başlangıç tarihi: 8. Nisan. 2013
Bitiş tarihi: 8. Aralık. 2013
Çıktı: ISO/IEC 27001 ISMS sertifikası
Yazılım Projeleri Yönetimi
Ne zaman ki yazılım ürünlerin bir parçası haline geldi o zaman dünyanın aklı karışmaya Eminim Şaka Yapıyorsunuz Bay Feynman Kalem ya da motor parçası ya da bir kutu değildi ki bu. Üretim bandında ölçümler yapıp süreç adımlarını iyileştirme pek uygulanamıyordu (en azından başlangıçta).
Söz konusu olan yazılımdı ve tabii ki ilk ürünler savunma araçları idi. Kritik sistemlerdi. Manhattan Projesi'ni ilk örneklerden biri olarak düşünebiliriz. Manhattan Projesi 1939 yılında başlayıp 130 000'den fazla çalışanı ve yaklasık 2 milyar dolara (bugünün parası ile 26 milyar dolara) mal olmuştur bkz. Richard P. Feynman bu projenin üyelerinden biriydi. Hayatında gördüğü en güçlü bilgisayarın bu projede kullanıldığını ve işlemlerin nasıl yapıldığını Eminim Şaka Yapıyorsunuz Bay Feynman kitabında anlatmıştır.
Yazılım geliştirme projesine başladığında istenen ile sonunda çıkan ya pek aynı olmuyordu. Ya da, istenen elde ediliyordu da ayrılan bütçeden kat be kat fazlaya mal oluyordu.
İşin içinden çıkılamadığında da "Amaan, ArGe (!) zaten bu proje" denilip başarısızlığın üstü güzelce örtülüyordu.
Zaman geçtikçe yazılım geliştirme süreçlerinin kontrol altına alınması, proje yönetiminin de yazılım işlerinden anlar hale gelmesi en önemli beklenti olmaya başlandı.
En çok yazılım projesi yöneticileri ve takım üyelerinin kafa patlattığı bir kavramdır yazılım projesi yönetimi. Gerçek vakalar ile PMBOK 5. sürümü temel alarak elimden geldiğince yardımcı bir çalışmayı bu blog aracılığı ile yapacağım bundan sonra.
PMI bir ek dokümanıolan SW PMBOK taslak olarak hazırladı. 2013 yılı başında gözden geçirilmesi için sitesinde yayımladı. Henüz resmi olarak yayımlamadı. Bu sebepten dolayı temel olarak PMBOK 5th Edition, gerektiğinde CMMI-DEV v1.3 ile diğer ilgili standart/modeller belirteç olarak kullanacağım yolumuzu daha gerçekçi kılmak için.
Girizgahı şimdilik bitiriyorum. Önümüzdeki günlerde hem beni hem de siz okuyucuları tatmin edecek bilgi birikimi blogda oluşması umudu ile.
Söz konusu olan yazılımdı ve tabii ki ilk ürünler savunma araçları idi. Kritik sistemlerdi. Manhattan Projesi'ni ilk örneklerden biri olarak düşünebiliriz. Manhattan Projesi 1939 yılında başlayıp 130 000'den fazla çalışanı ve yaklasık 2 milyar dolara (bugünün parası ile 26 milyar dolara) mal olmuştur bkz. Richard P. Feynman bu projenin üyelerinden biriydi. Hayatında gördüğü en güçlü bilgisayarın bu projede kullanıldığını ve işlemlerin nasıl yapıldığını Eminim Şaka Yapıyorsunuz Bay Feynman kitabında anlatmıştır.
Yazılım geliştirme projesine başladığında istenen ile sonunda çıkan ya pek aynı olmuyordu. Ya da, istenen elde ediliyordu da ayrılan bütçeden kat be kat fazlaya mal oluyordu.
İşin içinden çıkılamadığında da "Amaan, ArGe (!) zaten bu proje" denilip başarısızlığın üstü güzelce örtülüyordu.
Zaman geçtikçe yazılım geliştirme süreçlerinin kontrol altına alınması, proje yönetiminin de yazılım işlerinden anlar hale gelmesi en önemli beklenti olmaya başlandı.
En çok yazılım projesi yöneticileri ve takım üyelerinin kafa patlattığı bir kavramdır yazılım projesi yönetimi. Gerçek vakalar ile PMBOK 5. sürümü temel alarak elimden geldiğince yardımcı bir çalışmayı bu blog aracılığı ile yapacağım bundan sonra.
PMI bir ek dokümanıolan SW PMBOK taslak olarak hazırladı. 2013 yılı başında gözden geçirilmesi için sitesinde yayımladı. Henüz resmi olarak yayımlamadı. Bu sebepten dolayı temel olarak PMBOK 5th Edition, gerektiğinde CMMI-DEV v1.3 ile diğer ilgili standart/modeller belirteç olarak kullanacağım yolumuzu daha gerçekçi kılmak için.
Girizgahı şimdilik bitiriyorum. Önümüzdeki günlerde hem beni hem de siz okuyucuları tatmin edecek bilgi birikimi blogda oluşması umudu ile.
4 Nisan 2013 Perşembe
CMMI Süreç Alanları
CMMI 1.3 sürümü 4 ana kategoride 22 süreç alanından oluşmaktadır.
4 ana kategori şunlardır:
4 ana kategori şunlardır:
- Süreç Yönetimi (Process Management)
- Proje Yönetimi (Project Management)
- Engineering (Mühendislik)
- Destek (Support)
Bu kategorilerin içerdiği süreç alanları ait oldukları seviyelerden bağımsız olarak aşağıdaki şekilde verilmiştir. Şekildeki süreç alanları ingilizcedir. Analam karmaşası oluşmaması için orjinal dilinde bıraktım şimdilik. Herbirini tek tek açıklayacğım. O zaman türkçesini düzgün biçimde belirteceğim.
Kaydol:
Kayıtlar (Atom)

