Bir CMMI Seviye 5 Organizasyonel Performans Yönetim Projesi Örneği: Kod Kalitesini İyileştirmek Deniz GUNGOR, Yasemin Yiğit KURU, Pinar ORGUN, Esma ELBİR Huawei Turkey Research & Development Center Software Quality Department, Istanbul/Tur- key deniz.gungor@huawei.com, yasemin.yigit.kuru@huawei.com, pinar.orgun@huawei.com, esma.ayan@huawei.com Özet. Yazılım süreçleri için Bütünleşik Yetenek Olgunluk Modeli olan CMMI’a göre, bir organizasyonun kendi iş hedeflerini yakalayabilmesi için o organizasyonun performansını proaktif bir şekilde yönetmek gerekmektedir. Bu deneyim bildirisi, yazılımda geliştirmeler yapan Huawei Türkiye Arge Merkezi’nin CMMI 5.olgunluk seviyesi süreç alanlarından Organizasyonel Performans Yönetimi kapsamında gerçekleştirdiği yazılım kod kalitesini iyileştirme projesini içermektedir. İyileştirme projesi, Huawei Türkiye Arge’nin iş hedeflerine bağlı kalite süreç performans hedeflerinden biri olan Teslimat Sonrası Hata Yoğunluğu’nu azaltma hedefi doğrultusunda kod kalitesini iyileştirme üzerine hazırlanmıştır. Aynı zamanda projenin amacı, yapılan analizler, aksiyon planı ve sonuç değerlendirmesi hakkında bilgi verilmiştir. Bu deneyim bildirisinin yazılım kod kalitesini iyileştirmek isteyen ve CMMI Seviye 5 sertifikası almış veya alacak olan kurum/kuruluşlara örnek olacağı tahmin edilmektedir. Anahtar Kelimeler: Süreç İyileştirme, CMMI Seviye 5, Organizasyonel Performans Yö- netimi, Yazılım Kod Kalitesi A CMMI Level 5 Organizational Performance Management Project Example: Improving Code Quality Deniz GUNGOR, Yasemin Yiğit KURU, Pinar ORGUN, Esma ELBİR Huawei Turkey Research & Development Center Software Quality Department, Istanbul/Tur- key deniz.gungor@huawei.com, yasemin.yigit.kuru@huawei.com, pinar.orgun@huawei.com, esma.ayan@huawei.com 495 Abstract. According to CMMI, a Capability Maturity Model Integration for soft- ware processes, to achieve the business goals of an organization, it is necessary to proactively manage the performance of an organization. This experience report contains a project to improve the code quality of the Huawei Turkey Research and Development Center which is developing software, within the Organiza- tional Performance Management process area of the CMMI 5th level. The im- provement project is based on improving the software code quality in line with the reducing Post-Delivery Defect Density (Downstream Defect Density) which is one of the Huawei Turkey Research and Development Center's quality process performance objective that is connected with the business goal. Meanwhile, in- formation was given about the purpose of the project, analysis that has been made, action plan and the outcome evaluation. It is anticipated that this experi- ence statement will be an example for institutions / organizations that would like to improve their software code quality and get certified or will get certify CMMI Level 5. Keywords: Process Improvement, CMMI Level 5, Organizational Performance Management, Software Code Quality. 1 Giriş CMMI Organizasyonel Performans Yönetimi’nde amaç periyodik olarak iş hedeflerini kalite süreçperformans hedefleriyle birlikte gözden geçirmek ve gerekirse revize et- mektir. İş hedeflerinin günün şartlarına göre halen güncel olduğundan ve iş stratejileri ile aynı doğrultuda olduğundan emin olmak için hedeflerin değerlendirilmesi büyük önem taşır [1]. İş hedeflerine ulaşıldığının takibinin ve değerlendirmesinin yapılması için bu iş hedef- leri ile bağlantılı olan başlıca süreç metriklerinin organizasyonda belirlenmiş olması gerekmektedir. Hedeflerin gözden geçirilmesi aşamasına kadar belirlenen metriklerin veri alabilme frekansına göre toplanması gerekmektedir. Örnek olarak; belirli miktarda verisi olan metrikler yıllık bazda değerlendirilebilir, değerlendirme sırasında önceden belirlenmiş limitlerin ve hedeflerin içinde olup olmadığı kontrol edilir. Kontrol sonu- cunda limit dışında çıkan ve iş hedeflerini en çok etkileyen metrikler verilerle analiz edilir ve bu metrikler için iyileştirme projeleri gerçekleştirilebilir. Ayrıca üst yönetim o yıl odaklanılacak iş hedeflerini stratejik olarak belirleyebilir. Yönetimin stratejik ka- rarı ve hedefleri etkileyen metrik analiz sonuçları göz önünde bulundurularak iyileş- tirme projeleri belirlenir. Bu deneyim bildirisinde bilgisi verilen iyileştirme projesinin amacı, kaliteli ürün teslimatının başlıca hedefine ulaşmak ve iş hedefleriyle aynı doğ- rultuda olan organizasyonel düzeydeki iyileştirmeleri süreç odaklı ve sistematik bir şe- kilde uygulamaktır. Bu bildiri, Huawei Türkiye Arge Merkezi’nin süreç hedeflerinden olan Kaliteli Ürün Teslimatı’nı doğrudan etkileyen Teslimat Sonrası Hata Yoğunluğu metriğini konu almıştır. 496 2 İş Hedefleri ile Değerlendirme Huawei Türkiye Arge Merkezi’nde her yıl ana odaklanılacak ana iş alanları ve hedefleri belirlenir. Bu alanların belirlenmesinde Çin’de konumlanmış olan idare merkezi (He- adquarter) ve üst yönetim rol oynar. Bu iyileştirme projesinin gerçekleştirildiği yıl olan 2016’da belirlenen ana odaklanılacak iş hedefleri ise Müşteri Memnuniyeti ve Müşte- ride 0 Kritik Kalite Kazası idi. Bu hedefler aşağıda kısaca açıklanmıştır: Müşteri Memnuniyeti: Müşteri Memnuniyeti HTRDC’de (Huawei Türkiye Arge Merkezi) yönetilen ürün veya projelerin çeşitli özellikleri konusunda müşteri beklenti- sini ve mevcut memnuniyeti anlamak için kullanılan bir ölçüttür. Müşteride 0 Kritik Kalite Kazası: Bu hedefin amacı teslim edilen ürünler için müşteride 0 kalite kazası hedefini yakalamaktır. Kritik kalite kazaları, ciddi bir şekilde son kullanıcıyı etkileyen, müşteri yararına ve itibarına önemli kayıplar getiren, takibi için acil olarak kaynak tahsis edilmesini gerektiren kritik problemlerdir. Aşağıdaki şekil Müşteri Memnuniyeti ve Müşteride 0 Kritik Kalite Kazası iş hedeflerinin akışını özet- ler. (bkz.Şekil. 1) Şekil. 1. Müşteri Memnuniyeti ve Müşteride 0 Kritik Kalite Kazası İş Hedefleri Akış Şeması Analizler: 2015 ve 2016 yıllarına ait Teslimat Sonrası Hata Yoğunluğu ve Teslimat Sırasında Bilinen Hata Yoğunluğu metrikleri hesaplanıp aşağıdaki analiz yapılmıştır. (bkz.Şekil. 2) Teslimat Sonrası Hata Yoğunluğu = [(Teslimat Sırasın Bilinen Hata Sayısı + Müşte- ride Bulunan Hata Sayısı) * 1000 ] / İncelenen Yazılım Paketinin Kod Satırı (1) Teslimat Sırasında Bilinen Hata Yoğunluğu = (Teslimat Sırasında Açık Kalan Hata Sayısı * 1000) / İncelenen Yazılım Paketinin Kod Satırı (2) 497 Şekil. 2. Yıllık Teslimat Sonrası Hata Yoğunluğu ve Teslimat Sırasında Bilinen Hata Yoğun- luğu Trendleri Yorum:Yıl bazındaki verilere bakıldığında Teslimat Sonrası Hata Yoğunluğunun, Tes- limat Sırasında Bilinen Hata Yoğunluğundan daha fazla olduğu görülmektedir. 3 Problem Analizi 3.1 Genel Hata Analizi 2016 yılında HTRDC bazında yapılan süreç yetkinlik analizine göre, toplam tüm hata- lar içerisinde teslimat sonrası hataların yüzdesi yüksektir. Hedeflere göre teslimat son- rası hataların kritik ve major hata içermeyecek şekilde tüm hatalar içindeki yüzdesinin %5’ten fazla olmaması gerekmektedir. Ancak, mevcut süreç yetkinlik analizi [2] (PCB) teslimat sonrası hataların, tüm hatalar içindeki yüzdesinin %18 olduğunu göstermekte- dir. Organizasyonel bazda yapılan kök-neden analizine göre; teslimat sonrası hataların (Downstream Defect) artmasının nedeni, teslimat sırasında bilinen hatalardan (Delive- red Open Defect) ve kod gözden geçirme (code review) & geliştirme testi (development test) aşamalarında kaçan hataların Sistem Tasarım Doğrulama Testi (SDV) ve müşteri bulgu (post-delivery) hatası olarak sızmasıdır. Organizasyonel bazda analizi yapılan projelerin süreç yaşam döngülerinde inceleme ve test aşamaları sırasıyla; Gereksinim- lerin Gözden Geçirilmesi, Tasarımın Gözden Geçirilmesi, Kod Gözden Geçirme, Ge- liştirme Testi ve Sistem Tasarım Doğrulama Testi şeklindedir. Kaliteli Teslimatı iyi- leştirmek için, kod gözden geçirme & geliştirme testi süreçlerinin verimliliğini %30 iyileştirmek gerekmektedir (Bkz.Bölüm 3.4). Böylece bu süreçlerden kaçan hataların, sistem tasarım doğrulama testi ve müşteri bulgu hatası olarak kaçması engellenebilir. (Teslimat sonrası hatalarda %30 azalma ile). Ayrıca teslimat sonrasına hata sızmasını azaltmak için teslimat sırasında bilinen hatalar analiz edilerek erken fazlarda önleyici aksiyonlar alınmalıdır. 2016 yılında yapılmış olan HTRDC süreç yetkinlik analizine göre; tüm hatalar içeri- sinde (Teslimat sonrası hatalar dahil) SDV fazında bulunan hataların payı en yüksek oran olan %27’dir. Bu analizde, kod gözden geçirme ve geliştirme testi fazlarında bu- lunan hataların oranı SDV’ye göre daha azdır. 3.2 Pareto Analizi Aşağıdaki Pareto Analizi [3] grafiğinde (bkz.Şekil. 3) SDV hatalarının nedenleri çıka- rılmış ve bu hataların frekansı analiz edilmiştir. 498 Şekil. 3. SDV Hatalarının Sebepleri için Pareto Analizi Yorum: SDV hataları için yapılan Pareto Analizi grafiği, çoğu SDV hatasının sebebi- nin kodun mantığı yansıtmaması ve geliştirme testinin yetersiz olması olarak gösteri- yor. 3.3 Problem Tanımı Kaliteli teslimatı iyileştirmek için, Kalite Departmanı kod gözden geçirme ve geliştirme testi fazlarının verimliliğinin %30 artmasını ve böylece SDV ve teslimat sonrası hata- ların azalacağı sonucuna varmıştır. Analiz edilecek problem, SDV ve teslimat sonrası hataların sebebini bulmaktır. Ayrıca istatiksel bir programda (Minitab) yapılan İlişki- lendirme Analizlerine (Correlation Analysis) [4] göre aşağıdaki ilişkiler tespit edilmiş- tir: * Teslimat sonrası hatalar ile Kod Gözden Geçirme Hataları arasında negatif yönlü kuvvetli bir ilişki, * Teslimat sonrası hatalar ile Geliştirme Testi Hataları arasında negatif yönlükuvvetli bir ilişki, * Teslimat sonrası hatalar ile SDV öncesi hatalar arasında negatif yönlü kuvvetli bir ilişki, * Teslimat sonrası hatalar ile SDV hataları arasında negatif yönlü kuvvetli bir ilişki olduğu görülmüştür. Negatif yönlü ilişki, bir değerin artarken diğerinin azaldığını gösterir. Yapılan analiz- lerde pozitif yönlü ilişkiye rastlanılmamıştır. İlişkinin negatif/pozitif olduğunun tespi- tinde korelasyon katsayısının [5] işaretine bakılır; ilişki şiddetini anlamak için ise ko- relasyon katsayısının değerine bakılır. 3.4 Hedef Belirleme Projelerde tanımlanan aksiyonlar uygulandığında kod gözden geçirme ve geliştirme testi süreçlerinde %30 daha fazla efor harcanacağı öngörülmüştür. Efordaki bu artış, kod gözden geçirme ve geliştirme test süreçlerinde iyileştirme yapılıp, bu aktivitelere daha fazla vakit harcanacağı içindir. Revize edilmiş (kod gözden geçirme ve geliştirme testi aşamalarındaki iyileştirmelerin uygulandığı varsayılıyor) hedeflerle birlikte (bkz. Tablo 1) süreçperformans modeli (PPM) [6] ile yapılan tahminlemeye göre teslimat sonrası hatalar ve teslimat sırasında bilinen hatalar 0 olarak tahminlenmektedir. (Süreç Performans Modeli (PPM), Crystal Ball programı ve eski verileri kullanarak tahmin 499 yapabilen istatiksel bir programdır.) Ayrıca SDV hataları duyarlılık analizine [7] göre (sensivity analysis) artık iç hatalar içerisinde en çok paya sahip değildir ve kod gözden geçirme & geliştirme test hatalarının payı artmıştır. (bkz. Şekil. 4) Şekil. 4. SüreçPerformans Modeli ile Revize Edilen Hedeflerle Yapılan Analiz Yorum: Organizasyon bazında yapılan duyarlılık analizine (sensivity analysis) göre, erken fazlarda hataların büyük kısmının yakalandığında, SDV’de ve teslimat sonra- sında daha az hata bulunacağı görünmektedir. SüreçPerformans Modelinde (PPM) re- vize edilmiş hedeflerle ile tahmin edilen (SüreçPerformans Modeli ile simülasyon ya- pılarak istenen metriklerin tahminlenmesi) teslimat sonrası hatalar 0’dır, bu da HTRDC organizasyonel kalite hedefi ile uyuşmaktadır. İyileştirme projesinde odak noktası olan süreçlere bağlı metriklerin belirlenen hedef- leri, Tablo 1’de gösterilmiştir. Tablo 1’de bulunan Hedef sütunundaki metrikler, bir önceki proje hedeflerine göre %30 artmış veya azalmıştır. Kod gözden geçirme ve ge- liştirme testi hata yoğunluklarının artmasının sebebi, bu fazlarda daha fazla hata yaka- lanacağının hedeflenmesidir; SDV hata yoğunluğunun azalmasının sebebi ise, bu erken fazlarda daha fazla hata tespit edileceği ve SDV fazında daha az hata yakalanacağı için- dir. Hata Yoğunluğu metriğinin birimi ise, Hata Sayısı / 1000 Kod Satırıdır (Kilo Lines of Code). Hata Yoğunluğu = Aktivitede Tespit Edilen Hata Sayısı / (İncelenen Yazılım Paketinin Kod satırı / 1000) (3) Tablo 1. SüreçHedefleri Alt Süreçler Metrik Hedef Kod Gözden Geçirme Kod Gözden Geçirme 3.76 (Kod Gözden Geçirme Hata Yoğunluğu Hata Yoğunluğu 30% artış) Geliştirme Testi Geliştirme Testi Hata Yo- 2.86 (Geliştirme Testi Hata ğunluğu Yoğunluğu 30% artış) Sistem Tasarım Doğru- Sistem Tasarım Doğru- 3.24 (SDV Hata Yoğunluğu lama (SDV) lama Hata Yoğunluğu 30% azalma) (SDV) 500 4 SüreçAnalizi 4.1 Kök-Neden Analizi Kalite Departmanı ve ilgili proje yöneticileri veri toplayıp, Teslimat sonrası hataların ve SDV hatalarının nedenini anlamak için detaylı kök-neden analizi yapmıştır. Kök- neden analizinde balık kılçığı yöntemi [8] kullanılmıştır. (Bu yöntemde önerilen kök- nedenler belli kategori başlıkları altında toplanır.) Belirlenen kök-nedenler değerlendi- rilerek içerisinde çözüm üretilebilecek olanlar seçilmiştir. Seçilen kök-nedenler Tablo 2’de görüldüğü gibidir: Tablo 2. Kök-Nedenler İnsan Kaynaklı Kök- Metot Kay- Çevre Kay- ÖlçüKay- AraçKay- Nedenler naklı Kök- naklı Kök- naklı Kök- naklı Kök- Nedenler Nedenler Nedenler Nedenler *Kod gözden geçirme *Ürün bazlı *Manuel pa- *Teslimat *Geliştirme uzmanının azlığı kod gözden ket derleme sonrası oluşan testinde bir *Geliştiricilerin kod geçirme kont- problemi kay- hataları ölç- otomasyon ol- standartlar kılavuzları rol listesinin naklı eksik pa- mek için bir maması hakkında bilgi sahibi olmaması ket içeriği ol- metriğin ol- *Statik Kod olmaması *Benzer hata- ması maması kontrolüprog- *Geliştiricilerin kod ların örnek ramının olma- standart kuralları hak- alınacağı bir ması kında az bilgi sahibi ol- veritabanının ması olmaması *Kompleks hataları çö- zecek uzman bir takım üyesinin olmaması *Statik kod kontrolü için bir program olma- ması 4.2 Çözüm Seçimi Organizasyonel seviyedeki balık kılçığında seçilen kök-nedenler için bir çok çözüm önerisi listelenmiştir. Bu çözümler arasında seçim yapılırken, çözümlere maliyet/risk, yarar ve yarar-maliyet oranına göre 1-10 arası puanlar verilmiştir. Puanlandırma sonu- cunda, en ideal puanı alan (maliyeti makul, eforu orta/az ölçekli/yararı fazla) çözümler uygulanmak üzere seçilmiştir. 4.3 Aksiyon Planlama Önerilen çözüm önerileri değerlendirildikten sonra, seçilen çözümler için Tablo 3’de görüldüğü gibi aksiyon planı oluşturulmuştur. 501 Tablo 3. Aksiyon Planı Aksiyon Etkilenen Sorumlu Hedeflenen Tamam- Statü Süreç Tamam- lanma Ta- lanma Tarihi rihi Çalışanların yetkinli- Yetkinlik İlgili De- 23.03.2016 25.03.2016 Kapalı ğini arttırmak için Yönetimi partman kod standardı eğitim- Yöneticisi leri düzenlenecektir. Kod gözden geçirme İnsan Yö- İlgili De- 23.03.2016 25.03.2016 Kapalı için uzman havuzu netimi partman oluşturulacak. Yöneticisi Statik kod gözden ge- Yazılım İlgili De- 13.04.2016 13.04.2016 Kapalı çirme programı, kod Kodlama partman gözden geçirme kap- Prosedürü Yöneticisi samını arttırmak için sisteme entegre edile- cek. Yazılım geliştiricile- Yazılım İlgili De- 13.04.2016 13.04.2016 Kapalı rinin kendi yazdığı Kodlama partman kodu gözden geçir- Prosedürü Yöneticisi mesi için ürün bazlı kod gözden geçirme kontrol listesi hazırla- nacak. Geliştirme Testi aşa- Geliş- İlgili De- 21.04.2016 21.04.2016 Kapalı masında seçilen bir tirme partman Test Otomasyon Testi Yöneticisi Programı kullanıla- cak. HTRDC seviyesinde Yazılım İlgili De- 21.04.2016 21.04.2016 Kapalı bilinen hatalar veri ta- Kodlama partman banı oluşturulacak. Prosedürü Yöneticisi 4.4 Maliyet-Yarar Analizi SüreçPerformans Model’inde Kod Gözden Geçirme Hata Yoğunluğu, Geliştirme Testi Hata Yoğunluğu değerleri %30 arttırılarak ve SDV Hata Yoğunluğu %30 azaltılarak 1000 kod satırında yapılan tahminleme sonucunda Üretim Sonrası Hata Yoğunluğu de- ğerinin 12’den 0’a düştüğü gözlemlendi. Bu durumda, eski metrik verileri baz alınarak hesap yapıldığında, 1000 kod satırı için harcanabilecek hata çözüm eforunun azaldığı ve bir saatlik efora denk gelen ortalama Amerikan doları sabiti ile kazanılan efor baz alınarak maliyet hesabı yapıldığında önemli miktarda kazanım sağlanabileceği öngö- rülmüştür. 502 5 Sonuçlar Planlanan aksiyonlar belirlenmiş olan bir pilot, iki yaygınlaştırma projesinde denenmiştir. Bu denemeler aşamalı olarak devam etmiştir. Öncelikle pilot proje seçilip aksiyonlar bu projede uygunlanmıştır. Projenin bitiminde aksiyonların verimliliği, hedeflere ulaşılıp ulaşılmadığı yapılan istatiksel analizlerle –hipotez testi- [9] belir- lenmiştir. (Hipotez testi, istatiksel bir analiz programında yapılabilen ve eski-yeni veri karşılaştırmasını yapıp, istatiksel bir şekilde bu iki veri arasındaki farkı gösterebilen bir testtir. Bu test sonuçlarına göre, sonraki verinin önceki veriden veya hedeften ne kadar farklı olduğuna bakılarak yorum yapılır.) Bu analizler sonucunda, pilot projenin SDV fazında daha az hata bulunmuş ve aksiyonlar uygulanmadan önceki duruma göre bu fazdaki hata bulmak ve çözmek için harcanacak 9 saatlik efor kazanılmış ve önemli ölçüde maliyet karı elde edilmiştir. (Şirket gizliliği gerekçesiyle gerçek değer ver- ilmemiştir.) Uygulamaların pilot projede başarılı olduğu görüldüğünde, belirlenmiş aksiyonlar ve süreç güncellemeleri yaygınlaştırma projelerinde uygulanmıştır. Bu projelerin bitiminde de hipotez testi yapılarak aksiyonların verimliliği kontrol edilmiştir. Hipotez testi sonucuna göre bu projelerde de 9’ar saatlik efor kazanılmış ve önemli ölçüde mali- yet karı elde edilmiştir. Ayrıca müşteride çıkabilecek hata riski (yoğunluğu) düşmüş, daha güvenli ve sorunsuz ürün gönderimi yapılmaya başlanmıştır. Pilot ve yaygınlaştırma uygulamaları sonucunda, yapılan iyileştirme projesinin başarılı olduğu sonucuna varılmış ve bu aksiyonların standart süreç haline getirilmesi kararlaştırılmıştır. Standart süreç olan bu aksiyonların tüm organizasyon genelinde uy- gulanmasına karar verilmiştir. Referanslar 1. Chaudhary,M, Chopra,A : CMMI for Development: Implementation Guide (2017) 2. Nandyal,R.S. : Key Features of a Good Process Capability Baseline Report (2015) 3. Litten,D : Project Risk and Risk Management (2010) 4. Doc.Dr.Seval Kul Sayfası, http://www.p005.net/analiz/korelasyon-analizi, son erişim 2017/09/12 5. Hacettepe Üniversitesi Biyoistatistik Sayfası, http://www.biyoistatistik.hacettepe.edu.tr/li- sans/eczacilik/Korelasyon_Regresyon.pps, son erişim 2017/09/12 6. Stoddard, R.W, Linders,B, Sapp,E.M :Exactly What are Process Performance Models in the CMMI? (2007) 7. Oracle Crystal Ball Information Page, http://www.oracle.com/technetwork/midd- leware/crystalball/overview/sensitivity-chart-128074.pdf, son erişim 2017/09/12 8. Tr Wikipedia Sayfası, https://tr.wikipe- dia.org/wiki/Bal%C4%B1k_k%C4%B1l%C3%A7%C4%B1%C4%9F%C4%B1_diyag- ram%C4%B1, son erişim 2017/09/12 9. En Wikipedia Sayfası, https://en.wikipedia.org/wiki/Statistical_hypothesis_testing, son erişim 2017/09/12 503