Tuesday, May 27, 2008

ÜRÜN YAŞAM DÖNGÜSÜNDE AŞAMALARIN İŞLEVİ

(The Role of Phases in Product Life-Cycle)

Bir yaşam döngüsü(life-cycle) bir ürün fikri doğduğu an başlar ve o ürün piyasadan kalkıncaya kadar devam eder, yani bütün geliştirim, işletim ve bakım faaliyetlerini içerir.

Bir geliştirim projesinin ürünleri zamanında teslim edilmeli ve amacına uygun olmalıdır. Geliştirim faaliyetleri sistemli bir şekilde planlanmalı ve uygulanmalıdır. Bir ‘yaşam döngüsü modeli’ ilgili faaliyetleri aşamalar şeklinde yapılandırır ve bu aşamalarda neler yapılacağını tanımlar.

Bir ‘yaşam döngüsü yaklaşımı’ bir yaşam döngüsü modelinin temel aşamalarının bir bileşkesidir.
Bütün projeler aşağıdaki temel aşamaları içeren bir yaşam döngüsü modelini içermelidir.

1- Kullanıcı İstekleri Şartnamesinin Tanımlanışı
2- Ürün İstekleri Şartnamesinin Tanımlanışı
3- Yapısal Tasarımın Tanımlanışı
4- Ayrıntılı Tasarım ve İşin Gerçekleştirilişi
5- İşin İşletime Teslim Edilişi
6- İşletim ve Bakım

İlk dört aşama birer gözden geçirim denetlemesi ile biter. Büyüklük, konu alanı (bilimsel, yönetimsel, gerçek zaman vb), sistem yapısı ve geliştirim araçları, projenin nasıl bir ekip tarafından yapıldığı gibi seçenekler ne olursa olsun, bu aşamalar zorunludur. Yine de, bu unsurların her biri geliştirime yaklaşımı, teslim edilenlerin karakter ve içeriğini etkileyebilir.

Yaşam döngüsünde gelişimin göstergesi olan altı kilometre taşı vardır.
1- Kullanıcı İstekleri Şartnamesinin Onaylanışı
2- Ürün İstekleri Şartnamesinin Onaylanışı
3- Yapısal Tasarım Belgesinin Onaylanışı
4- Ayrınıtılı Tasarım Belgesi, Kullanım Kılavuzu, yapılan işini sonucu olan ürün ve kabul testini hazırdalık
5- Geçici Kabul belgesi ve Ürün Transfer Belgesi
6- Nihai Kabul Belgesi ve Proje Geçmişi Belgesinin teslimi.

Son kilometre taşı bu aşamanın sonunda değil, garanti süresinin sonunda biter.

Bu kilometre taşları başarılabilir bir kontrat ilişkisi için zorunlu olan en az koşulları içerir. Bütün projelerde bulunmalıdırlar. Uzun projelerde, teslim edilenlerin takip edilebilişi için ek kilometre taşları eklenmelidir.

Yazımın buraya kadar ki kısımını Avrupa Uzay Ajansı ESA’nın bir mühendislik standardından faydalanarak, soyulayış ve genelleştiriş yöntemi ile yazdım. İnancım, bu soyut yaklaşım doğru, geçerli ve en azından faydalıdır.

Şaşırtıcı olan, Software konusunda yaygın olan lifecycle çalışmalarının gerek hacim gerekse içerik ve kalite olarak Ağ Proje Yönetimi (Network Project Management) konusunda çok daha zayıf ve yeni oluşudur. Son dönemde ülkemizin önde gelen iki büyük kuruluşunun hazırladığı ağ tasarım dökümanlarını incelemek imkan ve fırsatını buldum. Yukarıda ESA’nın sözünü ettiği aşamalar ve bunlara ilişkin belgeler tek bir tasarım belgesine ve sürecine indirgenmişti.

Ağ tasarımı ve gerçekleştirilişi konusunun bu tür bir parçalı süreç olmadığı iddia edilebilir. Aynı şey yazılım için de ileri sürülebilir oysa… Ben konuyu soyut olarak tartışmak istiyorum. Neden bir yaşam döngüsünü aşamalara bölmek faydalıdır? Hatta, neden ESA, uzun sürecek projelerde ek aşamalar eklenişini tavsiye ediyor?

Bir projeyi, herhangi bir süreci aşamalara bölmek, özünde bir çeşit gruplayış yani bir çeşit soyutlayıştır. Her soyutlayış gibi aşamalara ayırmak, bilgi saklamağa imkan tanır. Bir aşama ile uğraşırken, diğer ya da önceki aşamalara yalnızca isim olarak ya da o aşamanın teslim edilebilir belgesi, yani o aşamanın sonuçları açısından bakarız. Diğer aşamaların kendi iç ayrıntıları ile ilgilenmeyiz.

Bir süreci aşamalara bölmek ve her aşamaya ilişkin teslim edilişi gerekli çıktıları belirlemek sürecin kontrol edilebilirliğini(governance) arttırır. Böylece proje sonu geldiğinde ‘surpriz’lerle karşılaşmak olasılığı azalır, sorunlar büyümeden farkına varılır.

Tekrarlanan projeler, benzerlik olasılığı daha çok olan alt adımların süreleri ve maliyetleri konusunda
tecrübe birikimine neden olur. Bu tecrübe maliyet ve süre hesaplarında ve bunun sonucunda yapılabilirlik(fizibilite) hesaplarında başarı şansını arttırır.

İzlenebilirlik kriteri (traceability) kullanıcı istekleri şartnamesinde numaralanmış bir isteğin, ayrınıtılı tasarım dökümanı üzerindeki bir grup numaralanmış maddeye kadar takip edilebilişini gerektirir.
İzlenebilirlik kriteri, kullanıcının isteklerinin söz verildiği gibi gerçekleştirilip gerçekleştirilmediği konusunda elle tutulur bilgi verir.

Standartları doğru uygulayan bir ekip ve müşterileri arasında doğal bir güven ilişkisi oluşur, oluşmalıdır. Müşteri ikide bir çalışanların masalarını dolaşıp ne yaptıklarını kontrol etmek ihtiyacı duymaz, kimin kimi ne zaman nasıl denetleyeceği bellidir, bir iş olmadığı zaman kimin sorumlu olduğunu kolaylıkla belirlersiniz. Bu durum müşteriye daha rahat ve esnek davranmak imkanını tanır ve sonuçta proje verimliliğini arttırır.

Ürün İstekleri Şartnamesi ile Müşteri İstekleri Şartnamesi arasında bir karşılaştırım daha proje başlangıcında, müşterinin bilinç durumunu ve onun ISO9000’e göre isteklerinin özünü (‘implied needs’) tespit eden üreticinin yaklaşım kalitesini ortaya koyar. Müşteri proje bitiminden çok önce isteklerinin hangilerinin gerçekleştirilebilir olduğunu bilir gerekirse yeni önlemler alabilir.

Kontrol edilebilirliğin artışı dolaylı olarak kişilerin ve ekibin kendilerinden farkındalığını arttırır. Bu da ekip kalitesini ve yapılan işin kalitesini arttırabilir.

Bu sırada, içine düşülebilecek bir tehlike, bu süreci gereksiz ölçüde ayrıntılı yürütmektir. Standartlar, kurallar vb biçimsel zorlamalar başarı için zorunlu olan disiplini sağlar. Biçimsel zorlamalar yerinde zamanında ve amaca ulaşmak için gerektiği kadar uygulanmalıdır. Bazı standartlarda uygulama esnekliğini belirleyici ve sınırlayıcı hükümler vardır.

Sanılanın aksine, standartların uygulanışı işleri zorlaştırmaz. Çünkü standartlar işleri kolaylaştırmak için geliştirilirler. Sorun, onların uygulanışındadır. Maalesef içinde bulunduğumuz son 20 yılda bir çok standart yeni geliştirilmiştir ve nasıl uygulanacakları hala tartışılmakta ve denenmektedir.