Yazılım Projesi Yönetimi & Proje-Fikir İlişkisi

Serhat ERDEM
6 min readOct 29, 2022

--

Proje- Fikir İlişkisi

Projelerin kaynağı fikirlerdir, bir fikrin proje olması için belirli özelliklere sahip olmalıdır, her fikir bir proje değildir. Aklınızda bir iş fikri var fakat bunun ne kadar maliyeti olacağını, nerede uygulanacağını, ne kadar sürede gerçekleşeceğini bilmiyorsanız bu fikriniz bir projeye dönüştürülemez demektir. Bir fikrin proje olması için ilgili soruların her birisine cevap vermesi gerekir.

Projeler, hesaplanabilen belirli bir bütçeye sahip, bir uygulama alanına sahip, belirli bir zaman aralığında gerçekleşmesi beklenen (ne kadar sürede yapılabileceği kestirilebilen) düşüncelerin ürünleridir.

Yazılım Projeleri Nasıl Yönetilir ?

En başından başlamak gerekirse, proje yönetiminde çekirdek kişileri toplamak gerekir.

Şekil 1 Proje Yönetimi (Çizim Google Drawings yardımıyla tarafımca oluşturulmuştur.)

Yazılım projesinin bir müşteriye teslim edileceğini düşünürsek, ilk olarak bir Yazılım Mimarına (Software Architect)’e ihtiyaç vardır. Çünkü, müşterinin projeden beklediği fonksiyonların ve gereksinimlerin teknik olarak mümkün olup olmadığını yani teknik fizibilitesini belirleyecek kişi yazılım mimarıdır, fakat sorun şu ki müşterimizin yazılım projemizden beklediği fonksiyon ve gereksinimleri doğru bir şekilde tanımlayabilmek için müşterinin içinde bulunduğu iş alanın jargonunu ve bu sektörün temel kavramlarını iyi bir şekilde bilen biri olmalı, bu kişi İş Analistidir. (Business Anlayts) İş Analisti, müşterinin tam olarak projeden beklediği gereksinimleri doğru bir şekilde tanımlar.

Tanımlanan bu bilgiler SRS (Yazılım Gereksinimleri Tanım Belgesi ing, Software Requirement Specification) belgesinin içeriğini oluşturur.

Yazılım Gereksinim Tanım Belgesinin içeriğini oluşturan temel unsurlar aşağıdaki gibidir :

· Projenin Amacı (Problem ve çözümü net bir şekilde içermeli)

· Projenin Hedef Kitlesi (Projeyi kullanacak kişiler)

· Projenin Kullanım Amacı

· Projenin Kapsamı (Geliştirilecek olan önerilen sistemin açıklamasını, tanımlaması genel hatlarıyla yapılır.)

· Proje Tanımlaması

· Kullanım İhtiyaçları

· Sistem Gereksinimleri

· Güvenlik Gereksinimleri

· Fonksiyonel Gereklilikler (örnek; kullanıcılar birbirlerine mesaj atabilecek)

· Fonksiyonel Olmayan Gereklilikler (örnek; 5000 kullanıcı simultane olarak uygulamada aktif rol oynayabilecek)

SRS yazılım proje geliştirmede kilit bir dokümandır. Eğer ki başarılı bir yazılım projesi geliştirmek istiyorsak, tüm yazılım gereksinimlerini açıklayan bu belgeyi titizlikle hazırlamalıyız. SRS belgesi olmadan geliştirilmeye çalışılan bir projede, müşterimiz istediğini gereksinimler net bir şekilde sağlanmadığı için üründen memnun kalmayacak, deadline konusunda zaman sıkıntıları yaşanacak, tanımlamalar net bir şekilde anlaşılamadığı için iletişim problemleri doğacak ve buna benzer birçok olumsuzluk nedeniyle proje zaman ve para kaybıyla sonuçlanacaktır.

Müşterinin projeden beklediği tüm gereksinimleri tanımladık ve projenin fikrini analiz ettik bir sonraki aşama ise Projenin Planlanması.

Projemizi planlayıp, planladığımız yapıları dokümante etmemiz gerekmektedir. (Yazılımda bir plan, etkinlik, yapılması gereken bir iş varsa mutlaka bunun bir dokümantasyonu yapılmalıdır, yazılımı oluşturan en önemli unsurlardan biri belgedir.)

Planlama Aşamasında Yapılması Gerekenler aşağıdaki gibidir,

· Proje planlamasının kapsamı belirlenmelidir.

· Projenin iş zaman çizelgesi (Work plan Schedule) çıkarılmalıdır

· Proje grubunun mimarisi oluşturulmalıdır (hangi grup hangi modüllerde çalışacak)

· Kullanılan özel geliştirme ortamları, geliştirme ortamları açıklanmalıdır.

· Projenin standartları, projede kullanılacak fonksiyonlar belirlenmelidir.

· Yazılım Kalite Güvence Planı (SQAP) tanımlanmalıdır.

· Yazılım Test Planı tanımlanmalıdır.

· Yazılım Bakım Planı tanımlanmalıdır.

· Kaynak yönetimi planlanmalıdır.

· İnsan, yazılım ve donanım kaynaklarının mimarisi titizlikle oluşturulmalıdır.

· Projenin oluşturulması için gereken bütçe hesaplanmalıdır, hesaplanan bu bütçe doğrultusunda Gantt diyagramları oluşturulmalıdır. (Gantt diyagramlarını proje zamanlamasını gösteren grafikerdir.)

· Proje grubunun yapısını diyagram şeklinde net olarak ifade etmelidir.

Projemizi yukardaki maddeler doğrultusunda planlayıp, ilgili belgelerin dokümantasyonunu yaptıktan sonra bir sonraki aşamamız Sistem Analizi ve İnceleme Süreci Olacak.

Sistem Analizi ve İnceleme Sürecinde yapılması gerekenler aşağıdaki gibidir.

· Daha önce oluşturulmuş mevcut projeleri incelenmelidir.

· Geliştirilecek olan sistemin mantıksal mimarisi oluşturulmalıdır.

· Gerekli kullanıcı arayüzleri oluşturulmalıdır.

· Use Case diyagramları oluşturulmalıdır. (use case diyagramları son kullanıcın sistemle olabilecek muhtemel etkileşimleri gösteren grafiksel bir yapıdır.)

· Mevcut sistemlerdeki eksiklikler incelenmeli ve önerilen sistemin bu eksikliklere nasıl çözüm bulacağı tanımlanmalıdır.

· Use Case diyagramları yardımıyla sistemimizin fonksiyonel modelleri tanımlanmalıdır.

· Her case için sistemin nasıl çalışacağı metin olarak dokümante edilmelidir.

· Sistemimizin arayüzleri tanıtılıp açıklanmalıdır.

Temel olarak sistem analizi, mevcut sistemleri incelendikten sonra sistemimizin lojik modelini oluşturmaktır. Bu aşamadan sonra sistemimizi tasarlamamız gerekir.

Sistem Tasarlama Aşağıdaki Eylemleri Gerektirir:

· Tasarım hakkında genel bilgi dokümanı oluşturulmalıdır.

· Sistemin kullanacağı data tasarlanmalıdır.

· Süreçler tasarlanmadır.

· Akış diyagramları kullanarak, sistemin tasarım mimarisi açıklanmalıdır.

· Seçilen mimarilerin açıklamaları ve seçim nedenleri verilmelidir.

· Her bir arayüzün kullanım amacı ve üzerinde çalışılan data modeli verilmelidir.

· Arayüzler tasarlandıktan sonra, onları fonksiyonel hale getirecek modüllerin de tasarımı yapılmalıdır.

· Her bir modelin kullanıcı profilleri, testinin nasıl yapılacağı, entegrasyonunun nasıl yapılacağı akış diyagramları ile net bir şekilde ifade edilmelidir.

· Güvenlik sistemi, arşivleme sistemi ve yedekleme sistemi gibi ortak alt sistemlerin tasarımı yapılmalıdır.

· Ortak alt sistemler hakkında bilgi verilip açıklanmalıdır. Modüller arasında ortak olarak kullanılan datalar açıklanmalıdır.

Sistem tasarımı aşaması inşa edilecek bir binanın projesini çizmek gibidir, artık binanın projesini çizdik sıra geldi inşa etmeye yani Gerçekleştirme Aşaması (Implementation Phaze).

Gerçekleştirme aşamasında yapılması gerekenler ise;

· Yazılım geliştirme ortamı oluşturulmalıdır.

· Kodlama şekli (stili) belirlenmelidir.

· Anormal durumlar analiz edilmelidir.

· Gerçekleştirme aşamamız için standartlar belirlenmelidir.

· Sistemimizin gerçekleştirilmesi için, ilgili programlama dilleri, özel araçlar, kütüphaneler, veri tabanı teknolojileri ve veri tabanı yönetim sistemi mimarileri gibi yapılar hakkında bilgileri dokümante edip geliştirici ekibine sunulmalıdır.

Her modül ekibinde kendi modülünü bağımsız olarak geliştirmeye imkân sağlayacak grup yapısı oluşturulmalıdır bu prodüktiviteyi arttıracağından sürecin daha hızlı ilerlemesi sağlayacaktır. Farklı modüllerde benzer fonksiyonlar üzerinde çalışan programcılar kendi aralarında akran değerlendirmesi yapmalıdır. Scrum takımı oluşturulup ürün sahibiyle her an için yakın temas halinde olunmalıdır. Geliştirici ekibi artımlı (incremental) bir strateji uygulamalıdır, müşteri nihai ürüne ulaşana dek artımlı stratejinin sonucu olan demolara sahip olduğunda boşa yatırım yaptığını düşünmeyecek ve daha memnun olacaktır. En önemlisi müşteri nihai yazılım projesinin sağlayacağı gereksinimlere asgari düzeyde demo sürümleri sayesinde erken erişim sağlayacağından sorunlarına kısmi ölçüde çözüm bulacak, geri bildirim ve isteklerini geliştirici ekibine doğrudan iletecektir.

Şekil 2 Scrum Takım Yapısı (Görsel Google Drawings ile Tarafımca Oluşturulmuştur.)

Gerçekleştirme fazının bir diğer önemli bölümü Doğrulama (Verificiation) ve Geçerleme (Validation) fazıdır.

Doğrulama ve Geçerleme fazında,

· Test konseptleri (kavramları) doğru bir şekilde açıklanmalı.

· Doğrulama ve Geçerleme yaşam döngüsü tanımlanmalı.

· Entegrasyon ve test stratejileri tanımlanmalı.

· Test standartları belirlenmeli.

· Doğrulama ve Geçerleme metotlarının neden ve nasıl kullanıldığını, nasıl yapıldığı Gannt diyagramları ile net bir şekilde tasvir edilmelidir.

· Test araçları ve onların nasıl çalıştığı verilmelidir.

Doğrulma ve Geçerlemenin aslında cevap aradığı nokta

Doğru yazılımı geliştirdik mi? (Geçerleme) ve yazılımı doğru bir şekilde geliştirdik mi? (Verificiaton) sorularıdır, bu soruların cevaplarında herhangi bir negatif unsur varsa bir sonraki demo versiyonunda düzeltilmesi amaçlanmaktadır. Doğrulama ve geçerleme fazları test ekibi tarafından gerçekleştirilen eylemlerdir, Geliştirici ekipleri kendi içerisinde testçiler barındırabilir bu üretken olmayı sağlamak, geliştirilen modülün kısmi ölçüde teknik testini gerçekleştirmek içindir. Doğrulama ve geçerleme işlemlerinin kalite lideri tarafından yönetilen profesyonel bir test ekibince gerçekleştirilmesi gerekmektedir.

Şekil 3 Artımlı Yaklaşım (Görsel Google Drawings ile Tarafımca Oluşturulmuştur.)

Şimdi toplamak gerekirse, binamızın projesini çizdik, temel hatlarıyla binamızın bir demo versiyonunu geliştirdik, müşterinin bizden istediği devasa rezidansı değil de şimdilik ona başını sokacağı müstakil bir ev tesis ettik (Yazılım fiziksel bir yapı değildir, realitede müstakil bir evi revize ederek artımlı model ile devasa bir rezidansa dönüştürmek maliyetli ve mantıksızdır. Fakat yazılımın teknik fizibilitesi bu sürece uyum sağlar, yazılımda bu çok mantıklı ve üretken bir eylemdir, üstüne koyularak ilerlenebilir, her demo tesliminde müşterinin geri bildirim ve istekleri öğrenilir ve bir sonraki demo tesliminde bunlar sağlanır. Süreçlerin kronolojik sıralamasını daha somut bir örnekle görmemiz açısından böyle bir örnek verilmiştir.)

Bir sonraki aşama Bakım ve Destek Süreci Olacaktır. Bakım ve Destekleme Sürecinde;

· Kurulum ile ilgili gerekli bilgiler verilmeli ve dokümante edilmeli.

· Yazılımın nasıl işletileceği, nasıl bakımının yapıldığı konusunda bilgiler verilmeli.

· Bakım ve Destek süreci standartları tanımlanmalıdır.

· Bakım ve Destekleme sürecinin kapsamı belirtilmelidir.

· Bakım ve Destekleme Standartları Belirtilmelidir

· Bakım aşamasında kullanılan özel araçlar varsa bunların tanıtımı yapılmalıdır.

· Bakımda hangi işlemlerin yapıldığı neden yapıldığı nasıl yapıldığı Gantt diyagramları ile net bir şekilde ifade edilmelidir.

Son olarak

Sonuç ve Kaynaklar başlığı altında gerçekleştirimi yapılan aktiviteler detaylı bir şekilde incelenmelidir. Projenin avantaj sağlayan yanları anlatılmalı, dezavantaj sağlayan yanları anlatılmalıdır. Geliştirmenin her aşamasında kullanılan her türlü kaynak doğru bir şekilde numaralandırılarak tasvir edilmelidir.

Kaynakça

Kaynak 1

Kaynak 2

Kaynak 3

Kaynak 4

--

--

Serhat ERDEM
Serhat ERDEM

Written by Serhat ERDEM

Fırat Üniversitesi yazılım mühendisliği öğrencisiyim, araştırdığım ve öğrendiğim bilgileri Medium aracılığı ile sizinle paylaşıyorum...

No responses yet