İçeriğe geç

YMH114 Yazılım Mühendisliğinin Temelleri

2019-2020 Bahar yarıyılı yazılım mühendisliğinin temelleri dersi ile ilgili paylaşımlar bu kısımdan yapılacaktır. Bu dersi alan öğrenciler algoritma ve programlama II dersinde verilen dönem projelerinin raporlarını belirtilen tarihe kadar tamamlamak zorundadırlar.

Raporlanan ödevler Final Sınav haftasında teslim edilecektir. Ödev formatı, döküman içeriği ve gereksinimler derslerde anlatıldığı gibi olacaktır. Ayrıca IEEE SRS formatı ve örnek proje taslağı da bu sayfada paylaşılacaktır.

Raporun değerlendirilmesinde rapor içeriğinin kaliteli ve yeterli olması ve içeriğinin benzerliğine göre puan verilecektir.

Yazılım mühendisliğinin temelleri dersi 3+0 lık bir derstir. Yani dersin laboratuvarı yoktur. Bu sebeple bu ders kapsamında kullanılacak yardımcı araçların kullanımı ve ilgili programların çıktılarının elde edilmesi öğrencinin sorumluluğundadır.


YAZILIM MÜHENDİSLİĞİNİN TEMELLERİ DERSİ KAPSAMINDA KULLANILABİLECEK PROJE DÖKÜMANTASYONU- ŞABLON VE İÇERİK TANIMLARI:

BU ŞABLON IEEE SRS şablonundan yararlanılarak oluşturulmuştur. IEEE software requirements spesification samples/examples  şeklinde aranarak benzer örnek proje formatları bulunabilir.

Yazılım Gereksinimleri Tanım Belgesi (YGTB/SRS)

 Yazılım geliştirme süreci ;

  • Gereksinim Analizi / Requirements (Requirements Analysis)
  • Spesifikasyon / Specification (Functional Specification)
  • Mimari / Architecture (Software Architecture)
  • Dizayn / Design (Software Design)
  • İmplementasyon (Programlama) / Implementation (Computer Programming)
  • Test / Testing (Software Testing)
  • Sahaya Yerleştirme / Deployment (Software Deployment)
  • Bakım / Maintenance (Software Maintenance)

aşamalarından oluşmaktadır.

YGTB, belgesinde geliştirilecek olan yazılımın işlevsel ve işlevsel olmayan gereksinimleri tanımlanır. Use-Case’ler, Kullanıcı arayüzleri, User Story‘ler, Kısıtlar, Mevcut Sistemin Analizi, Önerilen Sistemin Tasarımı ve ER diyagramları verilir.

Yazılım mühendisliği kapsamında YGTB için verilen verilen taslak şu şekildeydi:

Yazılım Gereksinimleri Tanımı

  1. Giriş

1.1    Amaç

[Belgenin amacını ve hedef kitlesini tanımlayın.] Sorun Analizi ve Hedef Analizi mutlaka yazılmalıdır.

1.2    Kapsam

[Belgenin kapsamını tanımlayın.

Bu kısımda tanımlanan kapsam, varsa bir üst seviye gereksinimlerde yer alan benzer ifadelerle (örneğin, Vizyon belgesi) tutarlı olmalıdır.]

1.3    Tanımlar ve Kısaltmalar

[Belgeyi anlamaya yardımcı olacak ve alana özel terim ve kavramın tanımlarını verin ve belge içinde kullanılan kısaltmaları alfabetik olarak listeleyin.]

1.4    Referanslar

[Bu belgenin referans aldığı tüm kaynakları; referans numarası, referans kodu, başlığı, sürümü ve tarihi ile birlikte listeleyin.

Bu belge şablonu için, “IEEE Std 830-1998: IEEE Recommended Practice for Software Requirements Specifications” referans alınmıştır.]

1.5    Dokümana Genel Bakış

[Belgenin sonraki bölümlerinde neler anlatıldığını özetleyin. Belgenin kullanımı ile ilgili (varsa) güvenlik ve gizlilik koşullarından bahsedebilirsiniz.]

  1. Genel Tanım

[Yazılım ürünü ve gereksinimlerini etkileyen genel faktörleri, izleyen başlıklar altında tanımlayın.]

2.1       Ürüne Bakış

[Bu belge kapsamında tanımlanan yazılım ürününün (varsa) diğer ürünlerle ilişkisini anlatın.

Yazılım ürünü bağımsızsa ve sadece kendini içeriyorsa belirtin. Eğer bu belge, daha büyük bir sisteminin parçası olan yazılım ürününü tanımlıyorsa, üst seviye bir bakışla yazılım ile parçası olduğu sistem arasında ilişkiyi kurun ve sistem ile diğer yazılımlar arasındaki arayüzleri belirtin.

Sistemin ana parçalarını, birbirleriyle olan ilişkilerini ve dış arayüzleri gösteren bir blok diyagram çizebilirsiniz.]

[Mevcut Sistemin İncelenmesini bu kısımda verebilirsiniz]

2.1.1    Sistem Arayüzleri

[Yazılım ile diğer sistemler arasındaki arayüzleri ve bu arayüz gereksinimlerinin karşılanması için sağlanması gereken işlevleri belirtin.]

2.1.2    Kullanıcı Arayüzleri

[Yazılım gereksinimlerinin karşılayacak, yazılım ile kullanıcısı arasındaki arayüzleri belirtin. Bu arayüzler için taslak ekran yapılarını, sayfa/ekran yapılarını, menü veya raporların içeriklerini tanımlayın (eklere de referans edebilirsiniz)].

2.1.3    Donanım Arayüzleri

[Yazılım ile sistemin donanım öğeleri arasındaki arayüzlerin mantıksal özelliklerini belirtin. Bu özelliklerin konfigürasyon tanımlarını verin.]

2.1.4    Yazılım Arayüzleri

[Kullanılacak olan diğer yazılımın ürünlerinin (veri yönetimi sistemi, işletim sistemi, modelleme araçları, vs) ve diğer uygulama sistemleri ile (varsa) arayüzlerinin özelliklerini belirtin. Her bir uygulama yazılımı için, kod, isim, tanım/sürüm no.ve kaynak bilgilerini belirtin.]

2.1.5    İletişim Arayüzleri

[İletişim ile ilgili arayüzler (varsa) belirtilir (protokoller vb.)]

2.1.6    Bellek Kısıtları

[Birincil ve ikincil bellek ile ilgili özellikleri ve kısıtları belirtin.]

2.1.7    Ürünün İşletimi

[Kullanıcı gereksinimi olarak yazılımın normal ve özel çalışma kiplerini, kullanım ile ilgili zamanlama kısıtlarını, yedekleme ve kurtarma kısıtlarını veya gereksinimlerini belirtin.]

2.1.8    Saha Uyumlama Gereksinimleri

[Ürünün alandaki işletimi için, yükleme sahasını uyumlama gereksinimlerini (örneğin, veri veya başlatma sırası gereksinimleri) belirtin.]

2.2       Ürün İşlevleri

[Yazılımın gerçekleştireceği ana işlevlerin, detaya girmeksizin bir özetini verin.

Bu bölüm için gereken ana işlevlerin özeti, daha üst seviye gereksinimlerin (örneğin, Vizyon belgesi) söz konusu yazılıma atanmış bölümlerinden alınabilir, ancak bu belgenin “3. Özel gereksinimler” kısmı ile de tutarlı olmalıdır.

İşlevleri, bu belgeyi ilk defa okuyacak herhangi birinin kolaylıkla anlayabilmesi için listelenmiş şekilde düzenleyebilirsiniz.

Farklı işlevleri ve aralarındaki ilişkileri gösterebilmek için metinsel ya da grafiksel gösterim kullanılabilir. Söz konusu diyagramlar ürünün tasarımını göstermez, sadece işlevler arasındaki mantıksal ilişkiyi ifade eder.]

2.3       Kullanıcı Özellikleri

[Kullanıcıların sahip olmaları gereken genel özellikleri (eğitim seviyesi, deneyim vb.) belirtin.]

2.4       Kısıtlar

[Geliştiriciyi kısıtlayabilecek herhangi bir öğe ile ilgili genel tanımları verin (örneğin; donanım kısıtları, uyulması beklenen yönergeler, geliştirme ortamı ve teknolojisi ile ilgili gereksinimler, güvenilirlik gereksinimleri, güvenlik ve gizlilik hususları vb.)]

2.5       Varsayımlar ve Bağımlılıklar

[Belgede belirtilen yazılım gereksinimlerini etkileyebilecek olan faktörleri listeleyin. Varsayım ve bağımlılıklar tasarım kısıtları değil, değişmeleri halinde gereksinimleri etkileyecek olan faktörlerdir.]

  1. Özel Gereksinimler

[Bu kısımda,geliştirme ve test etkinliklerini mümkün kılacak detay seviyesinde, tüm yazılım gereksinimlerini tanımlayın. Tanımlanan gereksinimler, tüm paydaşlar tarafından algılanabilir olmalıdır.

Gereksinimler, bütün sistem girdilerinin ve çıktılarının tanımı ile girdileri çıktılara dönüştüren işlevlerin tanımını içermelidir. Bunlarla ilişkili ve bunlara ek olarak, işlevsel olmayan (kalite) gereksinimlerini de tanımlayın.

Gereksinimler doğru, kesin, tam, tutarlı, doğrulanabilir, değiştirilebilir, izlenebilir ve önceliklendirilmiş olmalıdır.

Bütün gereksinimleri biricik (“unique”) olarak numaralandırın.

3.1       Harici Arayüz Gereksinimleri

[Bütün sistem girdilerinin ve çıktılarının detaylı tanımını verin. Bu tanımlar 2. kısımda sunulan bilgileri tamamlamalı / detaylandırmalı, orada verilen bilgilerin tekrarı olmamalıdır.

Bir sonraki bölümde tanımlanması istenen işlevsel gereksinimlerin işletilmesini destekleyecek kullanıcı arayüzlerine ilişkin detaylar bu bölümde tanımlanabilir. Kullanıcı arayüzü tanımlama için bir şablon Ek-A’da verilmiştir.]

3.2       İşlevsel gereksinimler

[Ürüne ait işlevsel gereksinimlerin detaylı tanımını verin.

Use-case esaslı gereksinim analizi yaptıysanız bu bölümde use-case modelini ve bu modeldeki öğeleri detaylı olarak tanımlayın. Seçtiğiniz use-case’lere ait senaryoları UML Etkinlik Diyagramları veya metin biçimde detaylandırabilirsiniz. Use-case’lerin metin biçimde detaylandırılması için bir şablon, Ek-B’de verilmiştir.]

3.3       Performans Gereksinimleri

[Yazılım ve/veya kullanıcı arayüzü ile ilgili statik ve dinamik, nicel performans gereksinimlerini tanımlayın. Statik gereksinimlere; desteklenecek eşzamanlı kullanıcı sayısı, desteklenecek istemci sayısı vb. örnek verilebilir. Bu tür gereksinimler ölçülebilir şekilde ifade edilmelidir.

Benzer özellikler: Hız (“speed”), saniyedeki işlem sayısı (“processed transactions/second”), ortalama maksimum cevap süresi (“average, maximum response time”), ekran tazeleme süresi (“screen refresh time”), işlem hacmi (“throughput”), kurtarma/kendine gelme süresi (“recovery time”), kaynak kullanımı (“resource usage”) – hafıza, disk vb., eş zamanlı desteklediği kullanıcı sayısı (“number of simultaneous users to be supported”), kapasite (“capacity”) – sistemin sağlayabileceği müşteri ya da işlem sayısı ]

3.4       Mantıksal Veritabanı Gereksinimleri

<Veritabanında tutulacak veriler ile ilgili mantıksal gereksinimleri tanımlayın. Veri varlıklarını ve aralarındaki ilişki ve bütünlük kısıtlarını belirtin. Bu gereksinimleri ifade etmek için E/R Diyagramı kullanabilirsiniz.]

3.5       Tasarım Kısıtları

[Standartlar, kullanıcı istekleri veya donanım kısıtlarına dayanan ve tasarımı gerçekleştirirken uyulması gereken kararları tanımlayın.]

3.6       Kalite Özellikleri

[Yazılım kalite özelliklerini tanımlayın.

Aşağıda bazı özellikler için açıklamalar ve örnekler verilmiştir.]

3.6.1    Güvenilirlik (“Reliability”)

[Yazılımın güvenilirliği yani yazılımın sunduğu servisin devam etmesi ile ilgili özelliktir.

Sistemin çökme sıklığı ve şiddeti, iki çökme arasında geçen ortalama süre (“MTTF: mean time to failure”), onarım için geçen ortalama süre (“MTTR: mean time to repair”), hata ya da kusur oranı (“bugs or defect rate”), maksimum hata ya da kusur oranı (    maximum bugs or defect rate”) gibi ölçevler tanımlayarak ifade edilebilir.]

3.6.2    Kullanılırlık (“Availability”)

[Yazılımın kullanıma hazır olması ile ilgili özelliğidir.

Yazılımın kullanım için uygun olma yüzdesi (“% of time available=MTTF/(MTTF+MTTR)”) ile ifade edilebilir.]

3.6.3    Güvenlik

[Yazılımın kazayla ya da kötü niyetle erişimine, kullanımına, değiştirilmesine, tahrip edilmesine ya da imhasına engel olmak için taşıması gereken özellikleridir.

Belirli şifreleme ve kriptografi ile ilgili tekniklerinin kullanımı, amaca özel kayıtların (“log”) ya da geçmiş verilerin tutulması, farklı modüllere/kullanıcılara belirli fonksiyonların atanması, programın bazı bölümleri arasında iletişimin kısıtlanması ve kritik değişkenler için veri bütünlüğünün kontrolü ile ifade edilebilir.]

3.6.4    Bakım-yapılabilirlik (“Maintainability”)

[Yazılımın kullanıma alındıktan sonra kolay bakım-yapılabilmesi için taşıması istenen özellikler belirtilir.]

3.6.5    Taşınabilirlik (“Portability”)

[Yazılımın başka platformlara (işletim sistemi, vb.) taşınabilirliği ile ilgili özellikler belirtilir.]

3.6.6    Kullanılabilirlik (“Usability”)

<Yazılımın kolay kullanılabilirliği ile ilgili özellikler belirtilir.

Uyulması gereken standartlar (kullanıcı arayüzü standartları, kullanıcı arayüzlerinin tutarlılığı, vb), çevrimiçi (“online”) ve içerik duyarlı (“context-sensitive”) yardım, sihirbazlar (“wizards”), kullanıcı dokümantasyonu, eğitim materyalleri ve eğitim süresi gerekleri tanımlanarak ifade edilebilir.]

  1. Gereksinimlerin Önceliği ve Kritikliği

[Bu belgede tanımlanan gereksinimlerin göreli önemlerini, önceliklerini ve varsa tanımlanmış ağırlıklarını yazın.]

  1. Gereksinimlerin İzlenebilirliği

[Bu belgenin “3. Özel Gereksinimler” başlığı altında tanımlanan yazılım gereksinimleri ile bir üst seviye gereksinimler (örneğin, Vizyon belgesi) arasında çift yönlü izlenebilirliği oluşturun.

İzlenebilirliği tablo yapısında oluşturabilirsiniz.]

  1. Ekler

[Bu belgenin yapısını basitleştirmek ve anlaşılmasını kolaylaştırmak için,içerikteki bazı bilgileri eklerde verebilirsiniz. Ana döküman içerisinde bilginin normalde sunulduğu yerde verilemeyen tanımlar için bu bölüm kullanılır.

Ekler, alfabetik olarak ve belge içinde referans edildiği sırada tanımlanmalıdır.]


BAZI UML VE DİYAGRAM ÇİZİM ARAÇLARI

Bu kısımda özellikle tümleşik modelleme dili, proje yönetim, çevik yazılım ve diğer metodolojilerde kullanılabilecek bazı çizim araçları ve bağlantıları verilmiştir.

ARGO UML;

http://argouml.tigris.org/

ALTOVA U MODEL;

https://www.altova.com/umodel.html

VISUAL PARADIGM  

https://www.visual-paradigm.com/download/community.jsp

IBM RATIONAL SOFTWARE ARCHITECT 

https://www.ibm.com/developerworks/downloads/r/architect/
Online Diagram Software

 GEN MY MODEL

https://www.genmymodel.com/

Microsoft Visio 

https://indir.firat.edu.tr 

BAZI PROJE YÖNETİM ARAÇLARI

REDMINE  ;

http://www.redmine.org/

Microsoft Project Professional 

https://indir.firat.edu.tr/

Taiga

https://taiga.io/

JIRA :

Jira Platformu: Jira Software, Bitpocket, Sourcetree, Bamboo, Clover, Fisheye, Crucible, Jira Service Dest, Jira Core, Confluence, Hipchat

https://www.atlassian.com/try

Versiyon Kontrol Sistemleri

Subversion

https://subversion.apache.org/


PROJELERİN DEĞERLENDİRME KRİTERLERİ NELERDİR?

Bu kısımda projelerin değerlendirme kriterlerinden bahsedilecektir. Projelerimiz için IEEE standartlarına göre belirlediğimiz dökümantasyon formatı yukarıda verilmiştir. Ancak yazılım yaşam döngüsündeki her fazda nelerin yapıldığının vurgulanması için “yazılım mühendisliğinin temelleri” dersinde verilen/önerilen proje şablonundaki isterler aşağıdaki tabloda verilmiştir. Proje dökümantasyonu için değerlendirme kriterleri, her faz için nelerin yapılacağı burada verilmiştir.

YMH114 YAZILIM MÜHENDİSLİĞİNİN TEMELLERİ DERSİ PROJE/ÖDEV DEĞERLENDİRME KRİTERLERİ
-Projeler, YMH114 dersinde anlatılan kriterlere göre yapılmalı ve rapor düzenine uyulmalıdır.

-Proje ödevinde sayfa sınırı yoktur. İçeriğe bağlı olarak değerlendirilecektir.
-Teslim edilen Proje dosyası içerisine, yapılan tüm çalışma dosyalarının
Edit’lenebilecek formatları dahil (.doc, .vsd, .psd, gibi formatları ayrıca tamamı .pdf olarak) DVD/CD ile teslim edilecektir.

-Proje uygulamalarını yapanlar, geliştirdikleri yazılımları ve yazılımlarını
geliştirdikleri ortam yazılımlarını da DVD’ye yükleyerek teslim edecektir.
– YMH114 dersini ilk kez alanlar için yazılım geliştirme zorunlu değildir, ancak
uygulama geliştirenler extra puan ile değerlendirilecektir.
– Proje içerisindeki bölümlerde olması gereken zorunlu çizelgeler, şekiller,
diyagramlar aşağıda belirtilmiştir.

– Genel olarak metinde Times New Roman, 12 punto, 1.5 satır aralığı, iki yana yaslı metin kullanılmalıdır.

PROJE DÖKÜMANTASYONUNDA BULUNMASI GEREKEN BÖLÜMLER VE AÇIKLAMALARI
1.Bölüm – Tanıtım Bu kısımda projenin amacı, kapsamı ve genel tanıtımı yapılmalıdır.
2.Bölüm – Planlama

Gant diyagramı çizilmelidir (Maliyet kestirim dökümanı doğrultusunda oluşturulacaktır).
Ekip yapısı şematik olarak verilmeli ayrıca bunların zaman iş planları gösterilmelidir.
– Proje planı içerisindeki alt planlama başlıkları (Şablondaki 2.8 ve 2.13 arası her bir planlama aşaması) için gant diyagramları verilmeli ve bu planlama aşamaları için yer alacak ekiplerin yapısı, zaman/iş planları ve her bir planlama aşamasında kullanılacak kaynaklar yazılmalıdır.

3.Bölüm – Çözümleme

– Bu kısımda konu ile alakalı örnek bir mevcut sistemin use case diyagramı ve sistemin işleyiş senaryosu verilmelidir.
– Mevcut sistemin eksik yönleri belirlenerek önerdiğiniz sistemin bu eksikliklerden hangilerine nasıl çözüm getirdiği açıklanmalıdır.
– Önerilen sistemin İşlevsel Model başlığı altında Use case diyagramları çizilmeli ve her bir senaryo için Text formatında senaryolar yazılmalıdır.
– Bilgi sistemleri/Nesneler başlığı altında önerilen sistemin Sınıf diyagramları çizilecek her bir sınıfın kullanım amacı kısaca açıklanacak senaryolarla ilişkisi verilecektir.
– Sınıfların nasıl kullanılacağı veri modelinde açıklanacak gerekirse veri tabanı yapısı ile ilişkisi verilecektir.
Önerilen sistemin arayüzleri kısaca tanıtılacaktır. Verilen arayüzlerin maliyet kestirim dokümanında kullanılıp kullanılmadığı incelenecektir. Kodlama yapılsa da yapılmasa da sistemde ne tür arayüzler kullanılacağı belirtilmelidir. Hiç kodlama yapılmayan projelerde ilgili arayüzler herhangi bir IDE (kodlar bağlanmaksızın) ile veya görsel bir başka tasarım aracıyla çizilebilir.

4.Bölüm – Tasarım

Sistemin tasarım mimarisi akış diyagramı olarak verilmelidir. Ancak diyagramın dışında verdiğiniz mimarinin açıklaması seçim nedenleri ile birlikte detaylı verilmelidir.
– Tasarım aşamasında her bir arabirim için kullanım amacı, üzerinde çalışacağı veri modeli, hangi testlerin uygulanacağı ve performans kriterlerinin ne olacağı verilmelidir.
– Arabirim tasarımların yapılmasının ardından fonksiyonel gereksinimleri sağlayacak modüllerin neler olacağı verilmelidir. Her bir modül için tasarımı, kullanıcı profilleri, entegrasyon ve test işlemlerinin nasıl yapılacağı akış diyagramı şeklinde verilmelidir.
– Varsa ortak alt sistemler açıklanmalı, modüller arası ortak veriler belirtilmelidir.

5.Bölüm – Gerçekleştirme
– Önerilen sistem gerçekleştirilirken hangi programlama dilinin ve araçlarının, hangi teknolojilerin neden seçildiği açıklanacaktır.
Veri tabanı yönetim sisteminin mimarisi verilmelidir. Çözümleme aşamasında verilen veri modeliyle ilişkili olmasına dikkat edilecektir. (5.2.2 başlığı altındaki tüm başlıklar detaylı olarak irdelenmelidir.)
– Gerçekleştirme aşamasında kullanılan standartlar verilmelidir.
– Gerçekleştirim aşamasında meydana gelebilecek olağan dışı durumlar belirlenmeli nasıl yönetileceği kısaca açıklanmalıdır.
Kod gözden geçirme işleminin nasıl yapılacağı verilmelidir.
6.Bölüm – Test
Doğrulama ve geçerleme işlemlerinin nasıl yapılacağına ilişkin iş zaman planı gant diyagramı olarak verilmelidir. (planlama aşamasında verilen test planı ile uyumlu olmasına dikkat edilecektir).
– Test (doğrulama) planı için hangi yöntemlerin neden ve nasıl kullanıldığı detaylı olarak açıklanmalıdır.
Kullanılacak test araçları varsa işleyişi kısaca açıklanmalıdır.
Önerilen sistem gerçekleştirilirken hangi test türü ve araçlarının neden seçildiği açıklanacaktır.
7.Bölüm – Bakım
– Yazılım kurulum aktiviteleri hakkında bilgiler verilmelidir.
– Kurulum sonrasında yerinde destek organizasyonu tarif edilmelidir.
– Kurulum ve entegrasyon aşamalarında yapılacaklar hakkında bilgiler
verilmelidir.
8.Bölüm – Sonuç
-Bu bölümde gerçekleştirilen uygulamanın detaylı bir biçimde değerlendirilmesi yapılmalıdır.
-Gerçekleştirilen sistemin mevcut sistemlerden farkı net bir biçimde ortaya konulmalıdır.
-Gerçekleştirilen sistemin hangi probleme çözüm ürettiği belirtilmelidir.
– Gerçekleştirilen sistemin mevcut sistemlere göre avantajları ve
dezavantajları anlatılmalı, sistem benzer diğer sistemlerle tablolar ile karşılaştırılmalıdır.
-Gerçekleştirilen sistemin dezavantajları değerlendirilerek gelecekte nasıl iyileştirilebileceği detayları ile anlatılmalıdır.
9.Bölüm – Kaynaklar
– Geliştirme süreçlerinin her aşamasında yararlanılan kaynaklar (Kitap, Makale, Ders Notu, İnternet Sitesi vb) numaralandırılarak yazılmalıdır.
– Buradaki kaynaklar sadece yararlanıldığı anlamında olmayıp, doküman içerisinde kaç numaralı kaynaktan nerede yararlanıldığı kaynak göstererek verilmelidir.

YAZILIM MÜHENDİSLİĞİNİN TEMELLERİ DERSİ GİRİŞ

YAZILIM MÜHENDİSLİĞİNİN TEMELLERİ DERSİ Proje Değerlendirme Ölçütleri

YAZILIM MÜHENDİSLİĞİNİN TEMELLERİ DERSİ Yazılım Gereksinim Belirtimleri SRS

YAZILIM MÜHENDİSLİĞİNİN TEMELLERİ DERSİ- PROJE YÖNETİMİ VE STRATEJİK BAKIŞ

YAZILIM MÜHENDİSLİĞİNİN TEMELLERİ DERSİ PROJE ŞABLONU

YAZILIM MÜHENDİSLİĞİNİN TEMELLERİ DERSİ- YAZILIM SÜREÇ MODELLERİ

1

2

3

4

5

6

7-

8-

9-

10-

11-

12-

13-

 

14-

 

15-

 

16-

 

17-

18-

19-

20-

21-

22-

23-

24-

25-

26-

27-

28-

29-