Analist Kim Değildir?

İş ve İhtiyaç Analizi, Yazılım Mühendisliği

Analistin aslında daha düzgün bir ifadeyle iş analistinin ve ihtiyaç analistinin kim olduğu ve neler yaptığı gibi konular üzerine burada bir kaç yazı yayınladım. Bu gece bu konu ile ilgili bakınırken şöyle bir yazı buldum. Yazının içinde “Analist Kim Değildir?” gibi bir başlık da vardı ve hoşuma gitti. Ben de çogu zaman eğitimlerde ya da danışmanlık hizmetlerimde “analist şu kelimeleri kullanmaz” vb. türden cümleler kuruyorum. Bu yüzden bu yazıdan da esinlenerek “Analist Kim Değildir?” diye sormak istedim. Bu yazıda ister iş ister ihtiyaç analisti olsun, sonuçta projelerde bu isimle anılan rolleri kastediyorum. Sistem analisti kavramına biraz soğuk baktığım için belki burada yazacağım ya da yazacağımız pek çok şey aslında sistem analistinin yaptıkları arasına girecektir.

Buraya şunları koyalım: “Analist kim değildir?”, “Analist neyi yapmaz?”, “Analist neyi konuşmaz” gibi analistin ne olduğunu tersinden giderek tanımlamaya çalışalım. Sizlerin de katkılarıyla bu listeyi uzatalım istiyorum. Hadi bakalım başlayalım:

Analist kim değildir?

  1. Analist programcı değildir.
  2. Analist proje yöneticisi değildir.
  3. Analist tester değildir.
  4. Analist postacı ya da taşıyıcı değildir. Analist “analitik/çözümlemeci”dir, değer katandır.
  5. “Analist, her hata alındığında başvurulan help desk değildir” dedi Nilay.
  6. “Analist, proje toplantısı organizatörü değildir” dedi Hakan.

Analist neler yapmaz?

  1. Analist kod yazmaz.
  2. Analist test yapmaz.
  3. …

Analist nelerden konuşmaz?

  1. Analist int, long ya da double demez. Analist tamsayı ya da noktalı sayı der ve varsa sayının kısıtlarını söyler.
  2. Analist “for loop”ından konuşmaz. Analist bir işi bir grubun üyelerine, tekrarlı olarak sırayla uygulamaktan bahseder.
  3. Analist fonksiyonlardan ya da metotlardan bahsetmez. Analist davranışlardan ya da sorumluluklardan bahseder.
  4. …

Siz ne düşünüyorsunuz?

Toplam görüntülenme sayısı: 2155

UML’i Nasıl Kullanabiliriz? – I

Yazılım Modelleme, Yazılım Mühendisliği

Bir önceki yazımızda “UML Nedir?” sorusunu cevaplamıştık.  Bu yazımızda da “UML’i projelerimizde nasıl etkin olarak kullanabiliriz?” sorusunu cevaplayalım.

İşin açıkçası ben UML’dan çok UML araçlarını kullandım 🙂 Ne demek şimdi bu? UML araçlarını Rational Rose ve TogetherJ ile ta UML’in ilk çıktığı günlerden bu yana kullanıyorum. Türkiye’ye döndükten sonra da yukarıdaki iki araç ve başka UML araçlarını kullandım. UML araçları sadece UML diyagramları ile modelleme yapmanızı sağlamaz, pek çoğu aynı zamanda “reverse-engineering” yapmanıza da izin verir. Yani bu araçlara, hali hazırda yazılmış olan kodu örneğin Java kaynak kodunuzu gösterirseniz size kaynak kodundan yola çıkarak bazı UML diyagramlarını çıkarır. Bu da muhtemelen çok az ve eskimiş, güncel olmayan dokümentasyona sahip olan kod yapısını anlayabilmek için en etkin yöntemdir. Pek çok programcı böyle durumlarda debugger kullanır; halbuki reverse-engineering ile oluşturulmuş özellikle sequence diyagramları, kodun akışını istediğiniz detayda göz önüne serer, çok daha yüksek seviyeli bir bakış kazandırır. Benzer şekilde class diyagramları ile de hem tip hiyerarşilerini (is-a) hem de bilme/sahip olma (association, has-a) yapılarını, tiplerin arayüzlerini vs. ortaya koyduğunuzda sistemin çalışmasını anlamanız kolaylaşır. (Bu amaçla debugger kullanmak çoğu zaman aşırı detaya girmeye sebep olduğundan çok zaman alır. Kod devralmış developerlara tavsiyem, önce böyle bir araçla büyük resmi görmeleri sonra gerekiyorsa debugger kullanmalarıdır.) Benim “UML’den çok UML araçlarını kullandım” cümlemden kastettiğim, UML’i modellemek amaçlı değil de malesef daha çok zaten yazılmış kodun modelini geri doğru çıkarma amaçlı kullanmış olduğumdur. Bu durum insanı daha çok “UML okur” yapar, faydalıdır, özellikle danışmanlık amacıyla gittiğiniz yerlerde var olan dokümantasyonsuz kodu anlamak için sihirli değnektir. Ama işin açıkçası UML’i kullanmaktan kastettiğimiz “UML yazar” olmaktır. Yani projenizde baştan başa UML’i kullanmaktır.

Peki UML’i baştan başa nasıl kullanırız sorusundan önce bir kaç şeyi daha açıklamam gerekli. Öncelikle şunu tespit edelim: UML modelleme araçlarına sahip olmak hatta UML kullanmak kaliteli yazılım geliştirmek anlamına gelmez. Ben bu ülkede, özellikle parası bol olan kurumlarda, Rational gibi UML modelleme araçları, ihtiyaç analizi yönetim sistemleri, test vb. yazılım kalitesi yönetimi yapan tonla aracı içeren suitlere deli gibi para akıtıldığına şahit oldum. (Rational şirketi 2002 yılında IBM tarafından satın alındı ve ürünleri artık IBM ürün kümesine katıldı. Zaten piyasaya çok farklı ve değişik yetkinlik ve fiyatta pek çok UML aracı da çıktığından artık Rational’ın ürünleri eski popülerliğine sahip değildir.) Bu masraflar hem lisans için hem de eğitim için yapılmakta. Ama benim şahit olduğum kurumların hiç birisi tonla para verdiği bu UML araçlarını ve UML modelleme çalışmalarını, yazılım geliştirme süreçlerine entegre edemedi. Sebebini araştırdığınızda ise genelde aynı cevapla karşılaştım: UML ile modelleme yapmak zaman alıyor! Buradan modelleme konusunda ciddi bir tecrübe sahibi olmadan ve modellemenin mahiyetini bilmeden dostalr alış-verişte olsun diye doğrudan teknoloji satın almanın ne kadar yanlış bir başlama noktası olduğunu da anlıyoruz.

İşin açıkçası her teknoloji gibi UML’in kendi başına hiç bir değeri yoktur. UML çalışıp size bir şey üreten bir yapı değildir, bir derleyici gibi bile değildir. UML, yazılım geliştirme ile ilgili zihninizdeki düşüncelerinizi, herkesin anlayabileceği standart bir dile ve anlamlı görsellere dökmenin yoludur. Bu yüzden UML kullanmak zaman almaz, zaman alan şey düşünmektir. Düşünmenin maliyeti yanında UML’i kullanmanın getirdiği ekstra yük ne kadar olabilir ki? Sonuçta yazılımı zihinde modelleyebilmenin de bir sınırı vardır, bir yerlere zihninizdeki modelleri yazmanız gerekli ki zihniniz düşünmeye devam edebilsin ve düşündüklerini farklı zihinlerle paylaşılabilsin. Dolayısıyla bu topraklarda UML aracı almaktan ziyade düşünmeye vakit ayırmaya başlamak daha önemli bir iştir. Yazılım hakkında, projemizin ya da ürünümüzün ihtiyaçları, riskleri, tasarlanması üzerine düşünelim, ama UML kullanmayalım, dert değil. Bir beyaz tahtaya farklı renkte kalemlerle düşündüklerimizi çizip takım arkadaşlarımızla paylaşalım, bu çizimler üzerinden tartışalım, başkaları da başka çizimler yapsın örneğin. İşte böyle bir yazılım geliştirme kültürüne sahip olalım ve inanın UML’e olan ihtiyaç kendiliğinden ortaya çıkacaktır. Herkes farklı notasyonlar kullanacak ve bir notasyon karmaşası dolayısıyla da iletişim problemi oluşacaktır. Bu durumda muhakkak UML gibi standart bir notasyon dilinin herkes tarafından öğrenilmesi son derece makul bir ihtiyaç haline gelecektir.

Tam da bu sebepten, sıklıkla karşılaştığım “Biz 2 günde UML öğrenmek istiyoruz” şeklinde istekler malesef UML’in doldurmaya çalıştığı boşlukla uyuşmuyor. Yazılımı modellemenin ne olduğunu bilmeyen, yazılım geliştirmeyle ilgisi sadece program yazmak noktasında kalmış kişilerin ya da takımların, “biz sadece UML öğrenmek istiyoruz” demeleri, araç kullanmadan “ben sadece ehliyet almak istiyorum” demekten ya da bir arkadaşımım deyişiyle “kişinin ihtiyacı okuma-yazma olduğu halde ben sadece harfleri öğreneyim” demesinden” farklı bir durum değildir.

UML ile ilgili bir diğer konu da UML’in bir yazılım geliştirme metodolojisi olmadığı gerçeğidir. UML kullanmak, kaliteli yazılım geliştirmenin garantisi değildir. Ya da UML, doğrudan herhangi bir nesne-merkezli yazılım geliştirme metodolojisi sunmaz, o tarafı size bırakır. Bu anlamda UML sadece bir araçtır. Dolayısıyla UML’i kullanmak iyi bir süreç işletmek anlamına gelmeyecektir. UML’i verimli bir şekilde kullanmak, eğer kısıtlı zaman ve imkan varsa olabildiğince yüksek katma değer sağlayacak şekilde kullanmak, UML’den sağlanacak faydayı arttıracaktır.

UML’i bir süreç içerisinde kullanmaktan kastım ise, en basitinden var olan 10 küsür diyagramın hepsini her zaman kullanmaya çalışmanın anlamsızlığıdır. Şu çok açık: UML 100 kişinin çalıştığı ve 3 senelik bir proje için farklı kullanılırken 5 kişinin kodu bir başkasından devralıp, geliştirmeye çalıştıkları bir başka proje için farklı kullanılmalıdır. Bu ise hem geliştirme sürecini hem de UML’in nerede nasıl katma değer yaratacağını bilmekten geçer. Ve bu da tamamen bilgi ve tecrübe sonucunda elde edilir, UML aracı ve eğitimi pazarlayanların, “UML kullanın bütün dertleriniz bitsin” şeklindeki sloganlarla değil.

Bir sonraki yazıda UML’in ve bileşenlerinin nasıl kullanılabileceğini ele almak üzere iyi günler diliyorum.

Toplam görüntülenme sayısı: 3060

UML Nedir?

Yazılım Modelleme, Yazılım Mühendisliği

UML, Unified Modeling Language’in (ya da dilimizdeki karşılığıyla Birleşik Modelleme Dili) kısaltmasıdır. UML, yazılım sistemlerinin tanımlanması ve tasarlanması amacıyla geliştirilmiş bir notasyon dilidir.

Aslında algoritmik ve süreçsel yapıları eskiden bu yana “akış diyagramları” (flow charts) ile ifade etmeye çalışıyoruz. Ben 1985 yılında İTÜ’de Fortran dersini alırken, akış diyagramları kullanarak algoritmik tasarımları nasıl yapabileceğimizi öğrenmiştik. Aslen “process chart” adıyla 1920’li yıllarda makina mühendislerinin kullanımı için ortaya çıkarılan bu diyagramın, haliyle yazılım elemanlarının her türlü durum ve davranışını ifade etmede başarılı olması düşünülemezdi. Nitekim 1987 yılında Harel, karmaşık durumlara sahip nesnelerin davranışlarını betimlemek amacıyla “durum diyagramı” (state diagram) isimli notasyonu geliştirdi. Aslında bu da 1940lı yıllarda geliştirilen ve sonlu durum makinalarını (finite-state machines) modellemeyi amaçlayan benzer durum diyagramı kavramı üzerine kurgulanmıştı.

1990lı yıllara geldiğimizde yukarıdaki diyagramdan da görebileceğimiz gibi nesne-merkezli dünyada farklı kişiler ve yaklaşımları öne çıkmıştı. Örneğin Grady Booch’un “Object-Oriented Analysis and Design with Applications” isimli kitabında anlattığı ve kendine has bulutsu şekillerle görsel olarak betimlediği yaklaşımı en bilinenlerdendi.

Booch’un Notasyonu

Benzer şekilde Rumbaugh ve arkadaşlarının “Object Modeling Technique” (OMT) isimli yaklaşımları, Avrupa’da Ivar Jacobsen’in “Object-Oriented Software Engineering” isimli kitabında “use-case” ve diyagramları merkezli OOSE yaklaşımı, Wirfs-Brock’un Responsibility-Driven Design ve Shlaer/Mellor’un “Object-Oriented System Analysis” (OOSA) metodu ile Coad/Yourdon’un yazdıkları kitap serileriyle ortaya koydukları “Object-Oriented Analysis” (OOA) metodu zamanında benim de yakından takip ettiklerimdendi.

1990lı yılların ortalarına geldiğimizde ABD Silikon Vadisi şirketlerinden olan Rational (Rational Software Corporation) Rumbaugh’la çalışmaya başladı ve hemen akabinde Jacobsen’in Objectory isimli şirketini de alarak Jacobsen’i de kadrosuna kattı. Rational zaten 1981’de kurulmuş ve o günden itibaren Booch önderliğinde önce Ada ve sonra da C++ için değişik geliştirme araçlarını piyasaya sürmekte olan bir “yazılım geliştirme” şirketiydi. Rational’ın ünlü Rose isimli modelleme ve geliştirme ortamı da bunlardan biriydi.

1995’e geldiğimizde bu üç arkadaş (three amigos) Rational çatısı altında çalışmaya ve metodoloji ve notasyonlarını birleştirmeye başladılar. Bu üç arkadaşın temelde yaptıkları şey, kendi tecrübeleri ve bilinen diğer yaklaşımlardan yola çıkarak, yazılım-yoğun bir sistemin ihtiyaçlarından tasarımına ve kurulumuna kadar farklı durumunu farklı açılardan  betimleyecek bir notasyon dili ortaya koymaktı. UML, farklı konferanslarda görücüye çıktı ve nihayetinde 1.1 sürümü 1997 sonunda Object Management Group (OMG) tarafından standart olarak kabul edildi. Ben o zamanları iyi hatırlıyorum ve UML’den sonra OO dünyasının diğer liderleri de kendi kitapalrında artık UML’i kullanmaya başladılar. Özellikle o zamanki isimleriyle Rational Rose ve TogetherJ UML’i kullanarak modelleme ve raporlama yapmaya izin veren en popüler araçlardandı. Ben her ikisini de en başından bu yana kullanmıştım.

UML temelde notasyonal bir dildir. UML ile görsel modelleme yaparak, dilin kaypaklığını giderip, daha matematiksel ve kesin bir ifade imkanı kazanırız. Bu anlamda UML yazılımı “gorülebilir” hale getirir.

UML herhangi bir dilden bağımsızdır ama nihayetinde nesne-merkezli yaklaşımı benimsediğı için içinde class, object, interface, inheritance gibi kavramlar ve ilgili notasyonları mevcuttur. UML çalıştırılabilir bir dil değildir ama “Executable UML” ismi altında çalışmalar mevcuttur. UML araçları, UML ile geliştirdiğiniz modellerden size istediğiniz dilde kod üretirler. Dolayısıyla modellerinize uygun bir iskelet koddan programlamaya başlama imkanınız olur.

UML, bir yazılım geliştirme sürecinde yer alan farklı fazlara yönelik farklı açıları betimleyecek şekilde farklı diyagramlara sahiptir. 1.1 sürümünde UML 9 tane diyagrama sahipti. Bu diyagramlar genel olarak structural (yapısal) ve behavioral (davranışsal) olmak üzere iki ayrı kategoride  ele alınabilir. Bunlar ve temel işlevleri şöyle sıralanabilir:

  • Use-case diyagramları, sistemin davranışsal yapısını ifade etmek (behavioral),
  • Activity diyagramları, use-case’lerin akışlarını modellemek (behavioral),
  • Class diyagramları, statik tip ilişkilerini ifade etmek (structural),
  • Object diyagramları, class diyagramlarının bir “t” anındaki durumunu betimlemek (structural),
  • State diyagramları ile karmaşık durumlara sahip olan nesnelerin davranışlarını betimlemek (behavioral),
  • Sequence ve colloboration diyagramları, use-caselerin tasarımlarını ve bu tasarımlar içinde nesnelerin dinamik davranışlarını betimlemek (behavioral),
  • Component diyagramı ile modülleri, bileşenleri ve aralarındaki ilişkileri betimlemek (structural),
  • Deployment diyagramı ile de yazılım sisteminin donanımsal unsurlarla birlikte test ya da gerçek ortam gibi, yazılımın kurulum yapılarını betimlemek (structural).

Aşağıda iki tane UML diyagramı örneği verilmiştir.

Use-case diyagramı

Class diyagramı

UML, 2005 yılında 2.0 sürümüyle birlikte ciddi bir şekilde gözden geçirilmiş ve zenginleştirilmiştir. Bu şekilde UML’deki diyagram sayısı 2.2 sürümünde 14’e çıkmıştır.

UML’in Diyagramları

UML’i, onun etiket (streotype) sistemini kullanarak kendi teknolojinize ve iş alanınıza daha yakın hale getirebilirsiniz. Örneğin UML’i kullanarak entity, service, controller ya da Müşeri, Hesap  vb. tipte sınıflar için notasyonlar oluşturabilirsiniz.

UML hakkındaki ilk yazımızı burada keselim. Bir sonraki yazıda UML’i nasıl kullanabiliriz, özellikle ülkemiz şartlarında en faydalı hale nasıl getirebiliriz konusunu ele alalım.

Bol UML’li günler diliyorum 🙂

Toplam görüntülenme sayısı: 16413

İstek mi İhtiyaç mı Yoksa Problem mi? – II

İş ve İhtiyaç Analizi, Yazılım Mühendisliği

Aynı başlıklı ilk yazıda istek ile ihtiyaç arasındaki ayırımdan bahsetmiş ve yazılımların başarısı açısından istekler yerine ihtiyaçlara yönelmenin gerekliliğini vurgulamıştık. Bu yazıda ihtiyaç kavramına biraz daha odaklanacağız ve “kapsam”ı ele alacağız.

İşin açıkçası ihtiyaçlara odaklanmak da projelerin başarısını garanti etmez ya da kullanıcılarını memnun etmez. Çünkü ihtiyaç, üzerine biraz daha düşünülmesi gereken bir kavramdır. Örneğin ihtiyaç noktasında sorulması gereken bazı sorular vardır. Bu sorulardan ilki, ihtiyacın gerçek olsa bile projenin kapsamında (scope) olup olmadığıdır. İsteklerinin üzerine düşünmeden onları ihtiyaç diye proje ekibine kabul ettirmeğe çalışmakla, aslında kapsam dışı olması gereken ihtiyaçları kapsama sokmak için proje ekibini ikna etmek arasında, projeyi riske sokmak açısından hiç bir fark yoktur.

Proje tanımından, bir projenin kapsamının ve hedeflerinin belli olması gerektiğini biliyoruz. Kapsam yönetimi, proje yönetim metodolojilerinin üzerinde önemle durduğu konulardandır. Proje kapsamından kasıt ise ihtiyaçlar açısından neyin projede ele alınacağı neyin ise proje dışında bırakılacağıdır. Kapsam, projenin sınırlarını belirler. Kapsamın önce belirlenmesi ve sonrasında kontrol edilmesi, yeni isteklerin ve değişikliklerin kapsamın içine girip girmediğine karar verilmesi, giriyorsa önceliklendirilmesi ve maliyetlendirilmesi, bu bağlamda yapılması gereken en temel çalışmalardandır. Bu noktada ihtiyaçlarını belirlerken sistemin kullanıcılarına düşen en temel şey ise ihtiyaçları arasında önce kapsam açısından bir öngörüde bulunmaları sonra da kapsam içinde olduğunu düşünüyorlarsa ihtiyacı önceliklendirmeleridir.

Gerek dünyada yazılım projelerinin başarısızlık sebepleri üzerine yapılan araştırmalar gerek ise benim ülkemizdeki yazılım projelerinden edindiğim tecrübeler, kapsamı düzgün yönetilmeyen projelerin bir süre sonra batağa saplandığını gösteriyor. Kapsam problemi, eğer proje iç BT birimi tarafından yapılıyorsa, yapılan işi proje tanımından çıkaracak noktaya kadar gidebiliyor. Bu durumda zaten hiç bitmeyen projeler ortaya çıkıyor. Yok proje eğer bir dış kuruma yaptırılıyorsa, bu durumda kurumlar arası özellikle finansal menfaatler söz konusu olduğundan, işler daha da sarpa sarabiliyor. Bu ikinci tip durumlarda projelerin ezici çoğunluğunun sabit maliyetle anlaşıldığı gerçeği de göz önüne alınırsa, durumun ne kadar riskli olduğu anlaşılır. Buradaki tek risk proje ekibinin riski değildir aslında. Yani, maliyet sabit tutulurken kapsamın genişlemesi sadece proje için o sabit maliyetin altına imza atan ekip sıkıntıya girmeyecektir. Projenin sahibi olan kurum da, ayırdığı kaynakları boşa sarfetmiş olma ve sonuçta motivasyonel açıdan son derece sıkıntılı bir duruma düşme gibi tehlikelerle karşı karşıya kalacaktır.

Peki bir ihtiyacın kapsam dahilinde olup olmadığına nasıl karar verilir? Aslında bu çok daha teknik bir soru olup farklı teknikler ve yaklaşımlarla halledilebilecek niteliktedir. Tabi olarak projenin stratejisi, iş hedefleri, paydaşların projeden beklentileri, elde etmek istedikleri fonksiyonellik vb. girdiler, projenin kapsamını oluştururken kullanılacak en temel ihtiyaçlardır. Projenin kapsamını belirlerken zaman zaman nelerin içinde olmadığını belirtmek de kafa karışıklıklarını gidermek açısından önemlidir. Kapsam belirlemede en temel problemler, paydaşların gerçekçi olmayan kapsam istekleri, birbiriyle çelişen ihtiyaçlar ve kapsam dahilindeki ihtiyaçların önceliklendirilmesi konusudur.

Paydaşların gerçekçi olmayan isteklere sahip olmalarının en temel sebebi, yöneticilerin sık rastlandığı üzere “ne isterseniz isteyin, yaptırın” tavrı kadar her şeyi “acil” ya da “blocker” statüsünde gören dolayısıyla ihtiyaçlarıyla ilgili herhangi bir önceliklendirme alışkanlığı olmayan kullanıcılardır. Oyuncaklarını paylaşmayan çocuk psikolojisiyle yazılım projelerine girdi sağlanamaz. Ayrıca projelerin pek çok farklı tipte kullanıcıları olduğu gerçeği göz önüne alındığında, her kullanıcı tipinin bu şekilde davranması durumunda projenin çok ciddi riske gireceği aşikardır. Bu tipten önceliklendirme problemlerini çözmek için “Project Champion” rolü ya da Scrum’daki “Product Owner” aslında biçilmiş bir kaftandır. Büyük yazılım projelerinde yukarıdaki bahsettiğim rollerde birden fazla kişi bulunabilir ve belki bu durumda bu rollerin en tepesindeki örneğin “Chief Product Owner” rolü bu noktada karar verici olabilir. Bu iki rolün yer almadığı projelerde iki taraftan yönetsel sorumluluklara sahip kişilerin bir araya gelip, projeyle ilgili karşılıklı özveride bulunarak, projenin yapılabilirliğini ve yetişebilirliğini garanti altına almaları çok sık karşılaştığımız durumlardandır. Burada aslolan, böyle bir noktaya gelmeden projedeki tarafların makul ölçülerde önceliklendirme yaparak anlaşma yoluna gitmeleri ve kapsamı bir kriz durumuna getirmenin sebep olduğu zaman, iş ve motivasyon kaybını önlemeleridir.

Yazılım mühendisliği literatürüne kapsamın yavaş yavaş büyümesi ve bu şekilde kontrolden çıkmasına “scope creep” denir. Bu durumla ilgili son derece komik ve bir o kadar da gerçekçi karikatürler mevcuttur:


Konuyla ilgisi açısından belki şu yazıma da bakabilirsiniz.

Buraya kadar ilk yazı dahil geldiğimiz noktayı şöyle özetleyebiliriz. Yazılım ihtiyaç analizi, adı üzerinde ihtiyaçlar üzerinden ilerler, istekler üzerinden değil. İsteklerini ifade eden kullanıcıların ve diğer paydaşların, bu isteklerin sistemin stratejik hedefleri, müşteri memnuniyeti, paydaş olarak kendi ihtiyaçları vb. girdilerle projenin kapsamını, proje ekibinin de yardımıyla, makul ölçülerde tutmalı ve daima genişleme eğiliminde olan kapsamın projenin başarısızlığına sebep olmasının önüne geçmelidirler.

Bir sonraki yazımızda kapsam dahilindeki ihtiyaçların önceliklendirmesini ele alalım.

Toplam görüntülenme sayısı: 1656

«< 46 47 48 49 50 >»