BT'de Sistem Analizi

From Systems analysis Wiki
Jump to navigation Jump to search

IT'de Sistem Analizi (Systems Analysis and Design) — ihtiyaçların belirlenmesini, gereksinimlerin resmileştirilmesini, konu alanının ve süreçlerin modellenmesini, alternatiflerin ve risklerin değerlendirilmesini kapsayan; fikirden işletmeye kadar bilgi sistemlerinin tasarımı ve geliştirilmesine yönelik bir yaklaşımdır. Başka bir deyişle, IT'de sistem analizi — uzmanların görevi incelediği, sistemin ne yapması gerektiğini belirlediği ve sistemin oluşturulmasına yönelik çözümler geliştirdiği bir geliştirme aşamasıdır.

Klasik sistem analizi — yalnızca yazılım geliştirmeyi değil, organizasyonel değişiklikleri, stratejileri ve diğer boyutları da kapsayan geniş bir uygulama yelpazesine sahiptir.[1] [2]

IT'de Sistem Analizinin Konusu ve Görevleri

IT'de sistem analizinin konusu — fikir ve gerekçelendirmeden uygulama ve işletmeye kadar tüm yaşam döngüsü boyunca bilgi sistemidir (yazılım ürünü ve/veya hizmet).

Sistem analizinin görevi — iş ihtiyaçlarını tutarlı ve doğrulanabilir bir gereksinim ile mimari kararlar kümesine dönüştürmektir: paydaşların hedeflerini ve kısıtlamalarını tespit edip belgelemek, gereksinimleri resmileştirmek, konu alanını ve süreçleri modellemek, alternatiflerin uygulanabilirliğini ve risklerini değerlendirmek ve seçilen mimariyi gerekçelendirmek. Sonuç olarak tutarlı belgeler oluşturulur ve gereksinimler, tasarım kararları ile testler arasında izlenebilir bağlantılar kurulur. Bu, geliştirme sürecinin yönetilebilirliğini ve kontrolünü sağlar.

Sistem analizinin görevleri şunlardır:

  • Paydaşların ihtiyaçlarının ve hedeflerinin belirlenmesi. Analist, müşterilerin, kullanıcıların ve diğer ilgili tarafların beklentilerini toplar ve netleştirir; görüşmeler, anketler, gözlem ve mevcut süreçlerin analizi kullanılır. Çıktı olarak, işlevsel («sistemin ne yapması gerektiği») ve işlevsel olmayan (güvenilirlik, performans, güvenlik vb.) ayrımı yapılmış birincil bir gereksinim spesifikasyonu oluşturulur.[1][2]
  • Gereksinimlerin resmileştirilmesi ve belgelenmesi. Talepler, doğrulanabilir gereksinimlere dönüştürülür. İyi formüle edilmiş bir gereksinim; açık ve belirsizlik içermeyen, eksiksiz, tutarlı, doğrulanabilir ve daha üst düzey hedeflere izlenebilir olmalıdır; gereksinim kümesi ise uyumlu ve bütünleşik olmalıdır.[3][4] Uygulamada standartlaştırılmış belgeler kullanılır: ISO/IEC/IEEE 29148'e göre SRS (Software Requirements Specification), ayrıca belirli sektörlerde URS (User Requirements Specification) ve işlevsel spesifikasyonlar.[5][6][7]
  • Sistemin analizi ve modellenmesi. Sistemin nasıl çalışacağını ve dış dünyayla nasıl etkileşeceğini anlamak için modeller oluşturulur: kullanım senaryoları için Use Case diyagramları, veri akışları ve iş süreçleri için DFD, sınıf/bileşen diyagramları vb. Modeller, alternatif çözümlerin ve mimarilerin karşılaştırılması için temel oluşturur.[8][9][10]
  • Uygulanabilirlik değerlendirmesi ve çözüm seçimi. Feasibility study (teknik, organizasyonel, ekonomik, takvim uygulanabilirliği) ve mimari alternatiflerin karşılaştırması (trade-off) yapılır. Mimarinin nitelik özelliklerine (örn. performans, ölçeklenebilirlik, değiştirilebilirlik) göre değerlendirilmesi için ATAM (Architecture Tradeoff Analysis Method) gibi yöntemler uygulanır.[11][12] Örneğin, monolitik ve mikro hizmet mimarisi [3] arasındaki seçim; sektörel kılavuzların önerilerine dayanarak açık ödünleşimler üzerine (işletme karmaşıklığına karşı bağımsız ölçeklenebilirlik ve teslimat hızı) kurulur.[13][14]
  • Proje artifaktlarının hazırlanması. Analiz sonucunda şunlar oluşturulur:
    • onaylanmış gereksinim spesifikasyonu (önem düzeyleri belirtilerek),
    • sistemin kavramsal modeli (diyagramlar/açıklamalar),
    • mimari ve tasarım kararları (veri şemaları, dış sistem arayüzleri),
    • uygulama planı (aşamalar/modüller).
    • Gereksinimlerin tasarım öğelerine ve testlere izlenebilirliğini (bidirectional traceability) sağlamak kritik önem taşır.[15][4]

Bir IT projesinin başarısı büyük ölçüde gereksinim ve mimari yönetim pratiklerinin olgunluğuna bağlıdır. McKinsey ve Oxford tarafından yürütülen bir araştırma, büyük IT projelerinin çoğunlukla bütçe ve zaman sınırlarını aştığını ortaya koymuştur. Bu araştırma aynı zamanda stratejiyi doğru yönetmenin, paydaşlarla etkileşimin ve gereksinimlerin usulüne uygun toplanmasının projenin başarısı veya başarısızlığı üzerinde ne denli belirleyici olduğunu vurgulamaktadır.[16]

IT Sistem Analizinde Yaklaşımlar ve Metodolojiler

IT'de sistem analizi, sistem düşüncesi ilkelerine ve yazılım geliştirmeye uyarlanmış yöntemlere dayanır. Pratikte «katı» ve «yumuşak» yaklaşımlar, yapısal metodolojiler, nesne yönelimli notasyonlar ile süreç ve gereksinim modelleme dilleri bir arada kullanılır.

  • Katı ve yumuşak yaklaşımlar. IT projelerinde katı yaklaşım (hard systems), önceden resmileştirilebilen hedefler ve gereksinimler ile «yukarıdan aşağıya» ayrıştırma ve tasarımı varsayar. Yumuşak yaklaşım (soft systems), hedeflerin belirsiz ve bakış açılarının çok sayıda olduğu durumlarda uygulanır: Soft Systems Methodology (SSM) öğeleri (örn. rich picture, kök tanımlar, CATWOE) sorunun anlaşılmasını ve istenen değişiklikleri uzlaştırmak için kullanılır; ardından sonuçlar biçimsel gereksinimlere dönüştürülür.[17][18]
  • SSM (Soft Systems Methodology) Metodolojisi. Özgün olarak Peter Checkland tarafından organizasyonel değişim için geliştirilen SSM, IT'nin proje öncesi aşamalarında yararlıdır: sorunlu durumun incelenmesinden ve kök tanımların (CATWOE aracılığıyla) oluşturulmasından, kavramsal modellerin gerçeklikle karşılaştırılmasına ve paydaşlar arasında uzlaşı sağlanmasına kadar.[19][20]
  • Yapısal metodolojiler: SADT/IDEF0. SADT sistemi bir işlev hiyerarşisi olarak modeller; standart IDEF0 notasyonu (IEEE 1320.1), işlevleri ve bunların I-C-O-M arayüzlerini (Inputs, Controls, Outputs, Mechanisms) sabitler. Yöntem, algoritmaları gözetmeksizin işlevsel ayrıştırma ve sistem sınırlarının uzlaştırılması için uygundur.[21][22]
  • Nesne yönelimli analiz: UML ve SysML (MBSE). UML, gereksinimler ve tasarım için temel dil haline gelmiştir (Use Case, sınıf, sıralama vb. diyagramlar) ve kullanıcılarla senaryo doğrulamasını kolaylaştırır; SysML, UML'yi sistem mühendisliği için genişletir (gereksinim diyagramları, parametrik diyagramlar) ve modelin gereksinimlerden testlere kadar tüm aşamalarda merkezi artifakt olduğu MBSE yaklaşımına dayanır.[23][24][25]
  • İş süreci modelleme: BPMN. BPMN standardı, süreçlerin grafik olarak tanımlanmasında kullanılır (havuzlar, iş akışları, olaylar, geçitler); gereksinim spesifikasyonlarında ve entegrasyonda as-is/to-be karşılaştırması da dahildir.[26][27]
  • Gereksinim mühendisliğiyle bağlantı. Süreç şu aşamaları kapsar: elicitation–analysis–specification–validation–change management; «iyi gereksinim» kriterleri ve SRS yapısı ISO/IEC/IEEE 29148 tarafından düzenlenmektedir. Önceliklendirme için MoSCoW (Must/Should/Could/Won't) teknikleri ve AHP gibi çok kriterli seçim yöntemleri kullanılır. Çevik süreçlerde sistem analizi faaliyetleri backlog refinement ve gereksinim izlenebilirliğine yansır.[28][29][30][31]
  • Sistem mühendisliğiyle bağlantı. Karmaşık (siber-fiziksel) sistemler için V-modeli uygulanır: «sol» kolda sistem analizi ve mimari, «sağ» kolda ise sol kol artifaktlarına bağlı entegrasyon, doğrulama ve geçerlilik kılma yer alır. Mimariyi nitelik özelliklerine göre değerlendirme yöntemleri arasında ATAM (trade-off analizi) bulunur.[32][33]

IT'de sistem analizi, vizyonun uzlaştırılmasına yönelik yumuşak yöntemlerden biçimsel notasyonlara ve standartlara kadar uzanan kanıtlanmış yaklaşımları bir araya getirir. Araçların seçimi görevin belirsizlik derecesine bağlıdır: belirsizliğin yüksek olduğu durumlarda SSM ve kolaylaştırmanın rolü artar; sınırların net olduğu durumlarda ise biçimsel modeller (UML/SysML, IDEF0, BPMN) ve standartlar ön plana çıkar.

IT Mimarisi ve Kurumsal Mimariyle İlişki

IT projelerinde sistem analizi, mimari tasarımla yakından ilişkilidir. Analist ve mimar rolleri örtüşür: analist gereksinimleri ve mantıksal modeli formüle eder, mimar ise çözümün hedef yapısını ve teknik ödünleşimleri belirler; çalışma ortaklaşa yürütülür.

  • IT sistemlerinin mimarisi. Dar anlamda yazılım mimarisi — bileşenlerin organizasyonu, aralarındaki ilişkiler ve çözümün tasarımında yol gösterici ilkelerdir. Analistin mimari stilleri (katmanlı, istemci-sunucu, mikro hizmet, olay güdümlü vb.) göz önünde bulundurması önemlidir; zira işlevsel olmayan gereksinimler (güvenilirlik, ölçeklenebilirlik, değiştirilebilirlik) çoğunlukla mimari kararları ve ödünleşimlerini belirler.[34][35] Analizin erken aşamasında mimari vizyon (high-level vision) oluşturulur ve gereksinimlerin uygulanabilirliğini doğrulamak amacıyla çözümün taslak çerçevesi çizilir (iterasyon süresi ve ayrıntı düzeyi metodolojiye göre değişir).[36]
  • Şablonlar ve ön kararlar. İşlevsel olmayan gereksinimleri karşılamak için mimari şablonlar (architectural patterns) kullanılır. Örneğin, asenkron iletişim ve gevşek bağlaşım için — olay güdümlü mimaride bir mesaj aracısı üzerinden publish–subscribe.[37]
  • TOGAF (The Open Group Architecture Framework). En yaygın kurumsal mimari çerçevelerinden biri; ADM (Architecture Development Method) ve mimari yönetim artifaktlarını (depo, kataloglar/matrisler, ilkeler) kapsar. TOGAF'ta gereksinim yönetimi, ADM'nin tüm fazlarına entegre edilmiş bir süreçtir.[36] Gereksinimlerin desteklenmesi ve izlenebilirlik için kataloglar ve matrisler (örn. gereksinimler ↔ hizmetler, işlevler ↔ bileşenler) kullanılır; Architecture Building Blocks ve Solution Building Blocks birbirinden ayrılır.[38][39] Kurumun ilkeleri ve standartları ilgili kataloglarda sabitlenerek proje ekipleri için dışsal işlevsel olmayan gereksinimler olarak işlev görür.[40] Çözümlerin hedef mimariyle uyumluluğu, mimari uyumluluk incelemesi (Architecture Compliance Review) prosedürüyle onaylanır.[41] TOGAF yaklaşımı, ön Architecture Vision ve ardından gelen ayrıntılandırmayı (veri/uygulama/teknoloji) göç planı ve gereksinim değişikliği yönetimiyle birlikte öngörür.[42][43]
  • Zachman Framework. 6×6 matris (perspektifler × «ne/nasıl/nerede/kim/ne zaman/neden» boyutları) olarak sunulan, kurumsal mimari artifaktlarının erken dönem ve etkili bir ontolojisidir. «Tasarımcı» satırı sistem analizi ve tasarımıyla örtüşür; sütunlar veri, işlev/süreç, roller, konum ve motivasyonun eksiksiz ele alınmasını tanımlar. Çerçeve bir sınıflandırma (metodoloji değil) işlevi görür ve kurumsal peyzajda çözüm tanımının eksiksizliğinin sağlanmasına yardımcı olur.[44]
  • Kurumsal Mimariyle (Enterprise Architecture, EA) İlişki. Sistem analisti EA bağlamında çalışır: yeni gereksinimler iş yetkinliklerine ve operasyonel modele izlenir; kurumun standartları ve temel kısıtlamaları (güvenlik, uyumluluk vb.) uygulanır.[45][36] Başlangıç aşamasında Architecture Vision (hedefler/kısıtlamalar, üst düzey gereksinimler) oluşturulur; ardından analist, vizyona ve kurumsal standartlara izlenebilirliği koruyarak ayrıntılandırır; standartlara uyulmaması mimari incelemelerde tespit edilir ve çözümün yeniden çalışılmasına yol açabilir.[36][46]

Sonuç olarak: sistem analizi ve mimari tasarım «gereksinimler → mimari kararlar → nitelik özellikleri ödünleşimleri» bağlantısını oluşturur. Yöntemlerin seçimi (stiller/şablonlar, TOGAF artifaktları, Zachman sınıflandırması) projenin niteliğine ve kurumsal mimari çerçevesine göre belirlenir.

Süreçler ve Pratikler

Sistem analizi, yazılımın tüm geliştirme ve işletme yaşam döngüsüne entegre edilir; iş hedeflerini, mimariyi ve teslimatı birbirine bağlar. Proje öncesi araştırmayı, yaklaşım seçimini, doğrulanabilir artifaktların oluşturulmasını ve güvenilirlik, performans, güvenlik ile bakım gereksinimlerini kapsar. Şelale modelinde analiz, tasarım ve uygulamadan önce gerçekleştirilir; çevik yöntemlerde iterasyonlar aracılığıyla sürekli olarak yürütülür; DevOps'ta ise işletme hedefleri ön plana çıkar. Yaklaşımdan bağımsız olarak analiz, izlenebilirliği, değişiklik ve risk yönetimini, mimari ödünleşimlerin belgelenmesini ve normatif kısıtlamaların gözetilmesini sağlayarak geliştirmeyi öngörülebilir ve yönetilebilir kılar.

  • Klasik SDLC (Waterfall). System Analysis & Requirements Definition aşaması, tasarım ve uygulamadan önce gelir; gereksinimler planlama ve sözleşme temeli olarak ayrıntılı bir SRS'de sabitleştirilir. Kararlı ve düzenlenmiş alanlarda etkilidir; gereksinimlerin «dondurulması» riskleri SRR/inceleme ve CCB aracılığıyla değişiklik yönetimiyle azaltılır.[47][48][49]
  • Çevik metodolojiler (Agile). Analiz süreklidir: nihai SRS yerine, backlog refinement sırasında kabul kriterleriyle birlikte kullanıcı hikayeleri (user stories) içeren bir ürün birikimi tutulur; BDD (Given–When–Then) uygulanır; bütünleşik mimari kaybı riski, erken mimari hazırlık ve gereksinimler ↔ uygulama/testler arasında şeffaf izlenebilirlikle telafi edilir.[50][51][52]
  • DevOps ve SRE. Sık yayınlar, «varsayılan olarak» işletim gereksinimlerini gerektirr: otomasyon, gözlemlenebilirlik, geri alma. İşlevsel olmayan gereksinimler SLO/SLI olarak formüle edilir, error budget yönetilir; birikim listesine log/metrik/iz/uyarı görevleri eklenir; kesintisiz yayın için blue/green ve benzeri örüntüler kullanılır.[53][54][55]
  • Gereksinim ve risk yönetimi. ALM'deki gereksinimler, görevler/yayınlar/kusurlarla bağlı statülere sahiptir; versiyon kontrolü, değişiklik etki analizi ve düzenli yeniden önceliklendirme zorunludur.[56][57]
  • Kalite güvencesi (QA). Kalite gereksinim aşamasında temellendirilir: inceleme, «Three Amigos», Acceptance Test Plan, kabul kriterlerinin otomatik testleri (BDD/ATDD).[58][59]
  • Gözlemlenebilirlik ve güvenilirlik. Gereksinimlere ölçülebilir hedefler ve kontrol yöntemleriyle birlikte SLA/SLO, MTTR ve MTBF dahil edilir; parametreler iş/işletme birimlerinden alınır ve mimari ile güvenilirlik testlerine yansıtılır.[60][61]

Metrikler ve Artifakt Kalitesi

Sistem analistinin çalışmasını ve sonuçlarının kalitesini değerlendirmek için genel kabul görmüş kriterler uygulanır. Kaliteli gereksinimler ve modeller başarılı bir projenin temelidir; bu nedenle tüm yaşam döngüsü boyunca yönetilir (elicitation → specification → verification/validation → change management). Gereksinim kalitesinin temel özellikleri ISO/IEC/IEEE 29148 ve (tarihsel olarak) IEEE 830 standartlarında düzenlenmektedir.[3][62][1]

  • Doğruluk (Correctness) — gereksinim, gerçek ihtiyacı yansıtır ve alan uzmanlarıyla mutabık kalınır; doğrulama (review/inspection, prototipler, senaryolar) ile onaylanır.[1][4]
  • Eksiksizlik (Completeness) — önemli boyutlar ve koşullar göz önünde bulundurulur.
    • Bireysel gereksinim eksiksizliği: gerekli ayrıntılar belirtilir (örn. «gösterge hata durumunda kırmızıya geçer», yalnızca «kırmızı olur» değil).
    • Spesifikasyon eksiksizliği: senaryolar/roller kapsanır, NFR'ler tanımlanır; kontrol listeleri ve iş hedeflerine izlenebilirlikle sağlanır; bağımsız eksiksizlik denetimi (QA/review) yararlıdır.[3][63]
  • Belirsizlik içermeme (Unambiguity) — ifadeler tek bir biçimde yorumlanır; bu konuda sözlük, «sistem B olduğunda ve C ise A yapmalıdır» gibi şablonlar ve örnekler yardımcıdır; diyagramlara açıklama eklenmelidir. Doğrulama — «dört göz» ilkesi.[3][1]
  • Tutarlılık (Consistency) — gereksinimler birbirleriyle ve dış kısıtlamalarla çelişmez; yapılandırma, öznitelik özet tabloları, takım incelemeleri uygulanır; mevzuat/standartlar doğrulanır.[3][63]
  • Doğrulanabilirlik/Test Edilebilirlik (Verifiability) — başarı bir test/gösteri/analiz ile onaylanır; doğrulanamayan ifadeler ölçülebilir kriterlerle değiştirilir; NFR'ler için metrikler tanımlanır ve kabul kriterleri önceden belirlenir.[3][63]
  • Değiştirilebilirlik ve İzlenebilirlik (Modifiability & Traceability) — benzersiz ID'ler, mantıklı yapı («bir düşünce — bir paragraf»), yineleme yokluğu; «gereksinim ↔ kaynak/hedef/tasarım/test» bağlantıları korunur, izlenebilirlik matrisi (RTM) tutulur.[64][3]
  • Sıralama ve önceliklendirme — gereksinim kümesinin kalitesi; MoSCoW ve MCDM (örn. AHP) teknikleri kullanılır; iş birimlerinin katılımıyla gerçekleştirilen önceliklendirme planlama ve riskleri etkiler.[65][66]

Gereksinim kalitesi metrikleri (örnekler):[63][1]

  • gereksinim kusur yoğunluğu (100 gereksinimde gözlem sayısı);
  • temel sabitleme sonrasındaki değişiklik sayısı;
  • kapsam metrikleri: testleri olan gereksinimlerin oranı; iş hedeflerine izlenebilir gereksinimlerin oranı;
  • gereksinim kararlılığı (bir dönemde eklenen/silinen ile toplam sayı arasındaki oran);
  • spesifikasyon boyutu/karmaşıklığı (bir use case'deki ortalama gereksinim sayısı, ayrıştırma derinliği);
  • paydaş memnuniyeti (anket).

Olgun süreçlerde (örn. CMMI düzey 3+) gereksinim kalitesi yönetmelikleri uygulanır: resmi incelemeler, şablon uyumluluk denetimleri, metrik toplama/analiz.[67] Kritik alanlarda (havacılık, uzay vb.) güvenilirliği artırmak için biçimsel yöntemler kullanılır.[68]

Tipik Hatalar

IT projelerinde sıkça rastlanan sistem analizi hataları şunlardır: gereksinimlerin eksik ve belirsiz olması, çelişkiler, bulanık sınırlar, işlevsel olmayan boyutların göz ardı edilmesi, atlanmış entegrasyon ve geç kalan güvenlik. Bu durum yeniden çalışmalara, gecikmelere, maliyet artışlarına ve hatalara yol açar.

Tipik sorunlar, sonuçları ve önleme yolları.

  • Eksik ve atlanmış gereksinimler. Özel haklara sahip roller, sınır durumları ve NFR'ler gözden kaçırılır. Sonuçlar: mimari yeniden yapılandırma ve yayın ertelemesi. Önleme yolları: kontrol listeleri, «ya … olursa?» beyin fırtınaları, test uzmanlarının erken dahil edilmesi, iş hedeflerine izlenebilirlik.[1][69]
  • Belirsiz, muğlak ifadeler. Sonuçlar: geliştiriciler «yanlış» şeyi uygular, müşteri memnun olmaz. Önleme yolları: ölçülebilir kriterler, sözlük, «B olduğunda ve C ise A» şablonları, peer‑review.[3][69]
  • Çelişkili gereksinimler. Sonuçlar: netleştirme nedeniyle gecikmeler, entegrasyonda yeniden çalışmalar. Önleme yolları: yapılandırma, iş kuralları/mevzuat doğrulaması, çatışma çözüm oturumları, incelemede tutarlılık denetimi.[3][1]
  • «Altın kaplama» sendromu (gold‑plating). Sonuçlar: kapsam büyümesi, karmaşıklık artışı, yeni hata noktaları. Önleme yolları: her gereksinimi bir hedef/metriğe bağlamak; Agile'da birikim listesine gereksiz öğe koymamak; kapsamı sabitlemek; bkz. YAGNI.
  • Gereksiz yerde aşırı ayrıntılandırma. Önleme yolları: ne/neden (gereksinimler) ile nasıl (tasarım/uygulama) ayrımını yapmak; uygun olduğunda design‑free requirements uygulamak.[3]
  • Gereksinim yönetilebilirliğinin bozulması. Sonuçlar: sürüm karmaşası, «yanlış»ın uygulanması. Önleme yolları: ALM'de tek doğru kaynak, geçmişe kayıt ve statüler, RTM ve değişiklik etki analizi; CCB aracılığıyla değişiklik yönetimi.[64][1]
  • Kullanıcı katılımının olmaması. Önleme yolları: görüşmeler, gözlem, prototipler, düzenli gösteriler; paydaşlarla açık doğrulama.[3][1]
  • Çok uzun «analitik felç». Önleme yolları: yeterlilik bölgesi, iteratiflik ve timeboxing; MVP/artırımların başlatılması ve geri bildirime göre düzeltme.[1]
  • İşlevsel olmayan gereksinimlerin göz ardı edilmesi. Önleme yolları: NFR'leri ayrıştırmak (örn. FURPS+), ölçülebilir kriterler belirlemek, test planına ve mimari kararlara dahil etmek.[1][3]
  • İletişim hataları ve «insan faktörü». Çözüm yolları: görüşme ve kolaylaştırma becerilerini geliştirmek, tarafsızlığı korumak, kararları ve gereksinim kaynaklarını kayıt altına almak (hedeflere izlenebilirlik).[1]

Sorunların büyük çoğunluğu ifade kalitesi, eksiksizlik ve gereksinim yönetilebilirliğine indirgenir; ISO/IEC/IEEE 29148 standartlarının ve SWEBOK pratiklerinin (doğrulanabilirlik, izlenebilirlik, iteratiflik) uygulanması, program kayması ve yeniden çalışma riskini önemli ölçüde azaltır.[3][1]

Sınırlılıklar

Belirsizliği azaltmadaki etkinliğine karşın, sistem analizinin kendine özgü sınırlılıkları bulunmaktadır:

  • Gerçeklik değişken ve karmaşıktır. Özellikle uzun vadeli projelerde tüm faktörleri hesaba katmak olanaksızdır. Bazı gereksinimler kaçınılmaz olarak sistemin devreye alınmasından sonra ortaya çıkacaktır. Sürprizleri en aza indirmeye çalışmak önemlidir; ancak değişikliklere hazırlıklı olmak gerekir.
  • Gereksinimler insanlara bağlıdır. İş öncelikleri, yasalar ve pazar değişebilir. Sistem analizi mevcut durumu sabitler ve tüm dış değişiklikleri öngöremez. Uyum sağlamak için gereksinimlerin düzenli olarak güncellenmesi ve iteratif çalışılması gerekir.
  • Kullanıcılar ne istediklerini görmeden her zaman bilemezler. Bu bilinen bir sınırlılıktır. Prototipleme ve Agile gibi çevik metodolojiler bu sorunu aşmaya yardımcı olur. Kağıt üzerindeki analizin sınırları vardır ve doğru veriler elde edebilmek için uygulamalardan geri bildirim almak gerekir.
  • Süre ile kalite arasındaki denge. Aşırı ayrıntılı analiz güncelliğini yitirebilir. İnovatif alanlarda en uygun yaklaşım, hızla minimum uygulanabilir ürün (MVP) oluşturmak ve gerçek veri elde etmektir. Sistem analizi kararlı alanlarda etkilidir; ancak araştırma projelerinde (R&D) rolü sınırlıdır.
  • İnsan faktörü. En iyi metodolojiler bile yetersiz analist ya da ulaşılamaz müşteriyi telafi edemez. Sürecin tüm katılımcılarının dahil ve motive olması önemlidir.

Modern Teknolojilerin IT'de Sistem Analizine Etkisi

IT'de sistem analizi, teknolojik yeniliklerin etkisiyle sürekli evrilmektedir. 21. yüzyıl analisti; veri patlaması, yapay zekanın her alana yayılması, hızlı geliştirme döngüsü ve güvenliğe artan ilgi koşullarında çalışmaktadır. Başarılı sistem analizi pratiği, yeni bilgilerin (Data Science, siber güvenlik, bulut teknolojileri) edinilmesini ve yöntemlerin uygulanmasında esnekliği gerektirmektedir.

  • Veri ve AI/ML: analize eklenenler. Yapay zeka sistemleri için başlangıçta uygulama hedefleri ve bağlamı, veri kaynaklarına ve kalitesine yönelik gereksinimler ile modelin kararlarına güven metrikleri (güvenilirlik, güvenlik, açıklanabilirlik, mahremiyet, adalet) belirlenir. TEVV (testing, evaluation, verification, validation) kontrolleri, işletmede izleme ve modelin güvenli devre dışı bırakılması/kaldırılması planlanır. Bu adımlar, NIST yapay zeka risk yönetimi çerçevesinin GOVERN–MAP–MEASURE–MANAGE işlevlerine karşılık gelir; SRS'e, mimariye ve doğrulama/işletme planlarına yansıtılır.[70]
  • DevSecOps: solda ve varsayılan olarak güvenlik. Her CI/CD aşamasına güvenliğin yerleştirilmesi norm haline gelmektedir: otomatik kontroller (SAST/DAST), bağımlılık ve konteyner tarama, dağıtım politikaları, temel gözlemlenebilirlik. Güvenilir artifakt kayıtları ve standartlaştırılmış «sertleştirilmiş» imajlar kullanılır; sıfır güven ilkeleri uygulanır. Sistem analizinde, boru hattı kontrol noktaları (aşamaları geçme koşulları), güvenlik kontrolleriyle gereksinim bağlantısı ve ortamlar arası geçiş kuralları (dev/test/stage/prod) önceden tanımlanır.[71]
  • Belgelerde (artifaktlarda) değişenler. Big Data ve AI/ML varlığında ve DevSecOps çalışmasında temel belgelerin hangi bölümünün eklendiği veya güncellenmesi:
    • SRS / Gereksinim Spesifikasyonu: yapay zekanın uygulama hedefleri ve bağlamı; veri gereksinimleri (köken, kalite, etik ve yasal kısıtlamalar); model metrikleri (doğruluk, güvenilirlik, yanıt süresi); TEVV planı (testing, evaluation, verification, validation); şeffaflık/açıklanabilirlik ve mahremiyet gereksinimleri; modelin devre dışı bırakılması/hizmet dışı alınma kriterleri.[70]
    • Mimari ve kararlar (Architecture, ADR): tehdit modelleme sonuçları; «varsayılan güvenlik» önlemleri (şifreleme, erişim denetimi, gizli bilgi yönetimi, en az ayrıcalık ilkesi); veri/model kullanım kısıtlamaları; risk ve ödünleşim değerlendirmesi içeren ADR kayıtları.[71][70]
    • Doğrulama ve Geçerlilik Kılma planı (V&V / TEVV): model ve veri testi senaryoları; kalite metrikleri için kabul eşikleri; veri/model sürüklenme izleme; periyodik yeniden değerlendirme ve yeniden geçerlilik kılma prosedürleri.[70]
    • CI/CD politikaları ve boru hattı «geçitleri»: otomatik SAST/DAST, SCA (bağımlılıklar), konteyner tarama; artifaktların güvenilir kayıtlarda imzalanması ve saklanması; ortamlar arası ilerleme kuralları (dev/test/stage/prod) ve kontrol başarısızlığı durumunda derlemeyi engelleme koşulları; varsayılan gözlemlenebilirlik gereksinimleri.[71]
    • Veri ve model yönetim planı: kaynak kataloğu ve lineage; veri kalitesi ve erişilebilirlik kriterleri; veri kümesi/model sürümleri; (yeniden) eğitim takvimi ve bias denetimi; erişim ve saklama politikası; gerektiğinde modelin güvenli devre dışı bırakılması ve veri silme planı.[70]
    • İşletme ve gözlemlenebilirlik (Ops/Runbook): yapay zekaya güven metrikleri ve SLO; denetim ve günlük tutma; bozulma/anomali uyarıları; olay müdahale planı; yapay zeka bileşenleri için fallback/kill‑switch; raporlama ve olay sonrası analiz gereksinimleri.[70][71]
    • İzlenebilirlik (end‑to‑end): «gereksinim ↔ boru hattındaki kontrol/doğrulama» ve «gereksinim ↔ işletmedeki test/izleme» açık bağlantıları; güvenliğin ve kalitenin tüm yaşam döngüsü boyunca kanıtlanabilir biçimde doğrulanabilmesi için.[71][70]
  • Sistem analistinin rolü.
    • yapay zekanın bağlamını ve risklerini yönetir (aktörler, uygulama senaryoları, veri varsayımları ve kısıtlamaları);
    • «gereksinim ↔ boru hattındaki güvenlik kontrolü» izlenebilirliğini sağlar;
    • sistemin tüm yaşam döngüsü boyunca doğrulanabilir işlevsel olmayan gereksinimleri (güvenlik, şeffaflık, gözlemlenebilirlik) formüle eder.[70][71]

Klasik Sistem Analizinden Farklılıklar

«Sistem analizi» terimi tarihsel olarak yazılım geliştirmeden daha geniş kapsamlıdır. Klasik sistem analizi — sistem düşüncesine ve nicel yöntemlere dayanan, genellikle yönetim kararlarını desteklemeye yönelik karmaşık disiplinlerarası sorunların (sosyal, ekonomik, yönetsel) çözümüne yönelik bir yaklaşımdır. IT'de sistem analizi, bilgi sistemlerinin oluşturulmasına odaklanan yazılım mühendisliği alanında uygulamalı bir disiplin olarak anlaşılır.

Aşağıda temel farklılıklar verilmiştir.

  • Analiz hedefleri ve nesnesi. Klasik analiz, kötü yapılandırılmış, «bulanık» sorunları çözer ve mevcut sosyo-teknik sistemleri (kentsel ulaşım ağı, şirket stratejisi, çevre politikası) iyileştirir. Nesne — gerçek sistem; görev — karar vericinin eylem yönü seçmesine yardımcı olmaktır. IT'de sistem analizi için hedef — gereksinimleri karşılayan yeni bir bilgi sistemi ya da yazılım ürünü tasarlamak ve oluşturmaktır. Nesne — tasarlanan sistem; odak — kullanıcılar için gereken davranış ve özellikler.
  • Metodolojik temeller'. Klasik okullar sistem düşüncesine ve çoğunlukla matematiğe dayanır. Katı yaklaşım (hard systems) — sorunun resmileştirilmesi, nicel kriterler, optimizasyon (operations researchteki gibi). Yumuşak metodolojiler (soft systems) bakış açısı çoklulğunu kabul eder; örnek — Soft Systems Methodology (SSM)de tartışmalar ve kavramsal modeller aracılığıyla istenen değişiklikler uzlaştırılır. IT'de temel — mühendislik disiplinleri: gereksinim mühendisliği, yazılım tasarımı, mimari çerçeveler. Standartlaştırılmış süreçler (ISO/IEC/IEEE 15288, 12207, 29148), UML/SysML notasyonları ve değişiklik yönetimi pratikleri uygulanır.
  • Roller ve artifaktlar. Klasik analizde «sistem analisti» rolü çoğunlukla biçimsel değildir; sonuçlar — analitik rapor, öneriler, matematiksel modeller, «ya olsaydı?» senaryoları. IT'de analist (veya iş analisti) rolü resmileştirilmiştir; gereksinim spesifikasyonları, sistem modelleri (UML, ER), arayüz spesifikasyonları, user stories ve backlog çıktı olarak üretilir — bunlar geliştiriciler ve test uzmanları tarafından doğrudan kullanılan artifaktlardır.
  • Yaşam döngüsü ve süreç. Klasik analizin tek bir şablonu yoktur: adımlar soruna bağlıdır (SSM'de durumun incelenmesinden değişiklik uygulamasına kadar). IT'de standart SDLC döngüleri benimsenmiştir: şelale modelinde ayrı bir gereksinim analizi aşaması bulunur; iteratif ve çevik yaklaşımlarda analiz, her sprint'in sürekli bir faaliyetidir. Modern pratikler (DevOps, CI/CD), analizin kapsamını işletime genişletir: bakım, gözlemlenebilirlik ve güncellenebilirlik gereksinimleri de göz önünde bulundurulur. Başka bir deyişle, IT'de sistem analizi geliştirme yaşam döngüsüne yerleşikken, klasik analiz daha çok proje/danışmanlık faaliyeti olarak yürütülür.

Sistem Analisti

IT'de sistem analisti — bilgi sistemlerinin tasarımı ve geliştirilmesinde sistem düşüncesinden sorumlu olan; gereksinimlerin oluşturulması ve doğrulanması, modelleme (UML/BPMN), mimari kararların uzlaştırılması ve entegrasyonun sağlanmasını üstlenen uzmandır. Rol ve yeterlilik gereksinimleri, Rusya Federasyonu'nda mesleki standart ve FGOS kapsamında düzenlenmektedir.

Mesleki faaliyetin temel amacı: IT hizmetinin, otomatik sistemin, otomatik bilgi sisteminin, otomatik yönetim sisteminin, yazılım, bilgi ürünü veya aracın (bundan böyle - Sistem) çevresine, başlangıç gereksinimlerine ve kısıtlamalarına, otomasyon hedeflerine ve otomatikleştirilen faaliyete uygunluğunun sağlanması; Sistemin tüm yaşam döngüsü boyunca kaliteli ve birbirine bağlı proje kararlarının ilgili taraflara hazırlanarak iletilmesi ve bireysel uygulayıcıların çalışmalarının başlatılıp koordine edilmesi yoluyla (Sistem Analisti Mesleki Standardı (Rusya Federasyonu Çalışma Bakanlığı'nın 27.04.2023 tarih ve № 367n sayılı emri).[72]

Temel Terimler Sözlüğü

Temel Kavramlar ve Katılımcılar

  • IT'de sistem analizi — fikir aşamasından işletmeye kadar tüm yaşam döngüsü boyunca bilgi sistemini konu alan disiplin.
  • Paydaşlar — projeye ilgi duyan veya projeden etkilenen kişi ya da gruplar (müşteriler, kullanıcılar, yöneticiler).
  • Proje artifaktları — proje sürecinde oluşturulan belgeler ve sonuçlar; spesifikasyonlar, modeller, planlar ve kararlar gibi.

Gereksinimler: Türler ve Belgeleme

  • İşlevsel gereksinimler — sistemin ne yapması gerektiğini; işlevlerini ve davranışını tanımlar.
  • İşlevsel olmayan gereksinimler — sistemin kalite özelliklerini tanımlar (güvenilirlik, performans, güvenlik, kullanılabilirlik, ölçeklenebilirlik vb.).
  • Gereksinim spesifikasyonu (birincil) — projenin başlangıç aşamalarında toplanan ilk gereksinim kümesini içeren belge.
  • SRS (Software Requirements Specification) — uluslararası standartlara (örn. ISO/IEC/IEEE 29148) göre yazılım gereksinimlerini ayrıntılı biçimde tanımlayan standartlaştırılmış belge.
  • URS (User Requirements Specification) — sisteme ilişkin kullanıcı gereksinimlerini iş süreci ve son kullanıcı beklentileri açısından tanımlayan belge.
  • Mimari açıdan kritik gereksinimler (ASR) — mimari kararları ve ödünleşimleri önemli ölçüde etkileyen gereksinimler.
  • Çapraz işlevsel gereksinimler (CFR) — işlevsel olmayan gereksinimlerin eş anlamlısı; kesişen niteliklerini vurgular.
  • Kabul kriterleri (Acceptance Criteria) — bir gereksinim üzerindeki çalışmanın kabul edilmiş sayılacağı doğrulanabilir koşullar.
  • Definition of Ready (DoR) — bir birikim öğesinin geliştirmeye hazır olduğuna dair anlaşma (netlik, tahmin, kriterler).
  • Definition of Done (DoD) — çalışmanın «tamamlandığına» dair anlaşma (kod, testler, belgeler, dağıtım).
  • Kısıtlama (Constraint) — çözümleri sınırlayan katı koşul (süreler, platformlar, standartlar, lisanslar).
  • Varsayım (Assumption) — kanıtlanmadan kabul edilen, sonradan doğrulama gerektiren öngörü.
  • Gereksinim kalitesi — ISO 29148'e göre özellikler: belirsizlik içermeme, eksiksizlik, tutarlılık, doğrulanabilirlik, atomiklik.

Gereksinimlerin Resmileştirilmesi, İzlenebilirliği ve Önceliklendirilmesi

  • Gereksinimlerin resmileştirilmesi — biçimsel olmayan taleplerin açık, doğrulanabilir ve belirsizlik içermeyen gereksinimlere dönüştürülmesi süreci.
  • Gereksinim izlenebilirliği — bir gereksinimin kaynağından uygulamaya, teste ve dağıtıma kadar yaşam döngüsünü izleyebilme olanağı.
  • Bidirectional traceability (çift yönlü izlenebilirlik) — gereksinimler, tasarım öğeleri ve test senaryoları arasındaki bağlantıları hem ileri hem de geri yönde izleyebilme kapasitesi.
  • MoSCoW — gereksinimleri Must-have (olmalı), Should-have (olması gerekir), Could-have (olabilir) ve Won't-have (olmayacak) olarak sınıflandıran önceliklendirme tekniği.
  • BDD (Behavior-Driven Development) — testlerin kullanıcı bakış açısından sistemin davranışına odaklanan doğal dilde yazıldığı geliştirme metodolojisi (Given–When–Then formatı).

Notasyonlar ve Modelleme

  • UML (Unified Modeling Language) — yazılım sistemlerinin bileşenlerini spesifiye etmek, görselleştirmek, inşa etmek ve belgelemek için standartlaştırılmış grafik modelleme dili.
  • SysML (Systems Modeling Language) — gereksinimler, davranış, yapı ve parametreler dahil olmak üzere karmaşık sistemlerin çeşitli boyutlarının modellenmesini destekleyen, sistem mühendisliğine yönelik UML uzantısı.
  • BPMN (Business Process Model and Notation) — iş akışlarını, olayları, geçitleri ve havuzları görselleştirmeye olanak tanıyan, iş süreçlerinin tanımlanması için grafik notasyon standardı.
  • MBSE (Model-Based Systems Engineering) — modelin gereksinimlerden teste kadar sistem yaşam döngüsünün tüm aşamalarında merkezi artifakt olduğu sistem mühendisliği yaklaşımı.
  • ArchiMate — kurumsal mimari (iş, uygulama, teknoloji) ve bunlar arasındaki ilişkilerin notasyonu.
  • DMN (Decision Model and Notation) — iş kararlarının ve kural tablolarının modellenmesi.
  • DFD (Data Flow Diagram) — veri akışı diyagramları (bağlam, ayrıştırma düzeyleri).
  • ERD (Entity-Relationship Diagram) — varlıklar, ilişkiler ve özniteliklerle alan modeli.
  • CRUD matrisi — Create/Read/Update/Delete işlemlerinin varlıklara ve rollere/işlevlere karşılık gelmesi.

Mimari Stiller ve Çözüm Değerlendirmesi

  • Monolitik mimari — tüm sistemin tek, bölünmez bir modül olarak geliştirildiği mimari yaklaşım.
  • Mikro hizmet mimarisi — sistemin bağımsız olarak dağıtılabilen ve ölçeklendirilebilen küçük hizmetler kümesi olarak oluşturulduğu mimari yaklaşım.
  • Trade-off (ödünleşim) — birbirine zıt veya çelişen özellikler ya da çözümler arasında, bir özelliğin iyileştirilmesinin diğerinin kötüleşmesi pahasına gerçekleştiği seçim.
  • ATAM (Architecture Tradeoff Analysis Method) — nitelik özellikleri (örn. performans, ölçeklenebilirlik) arasındaki ödünleşimleri analiz etmek için kullanılan yazılım mimarisi değerlendirme yöntemi.

Kurumsal Mimari ve Çerçeveler

  • TOGAF (The Open Group Architecture Framework) — mimari geliştirme ve yönetimi için ADM (Architecture Development Method) yöntemini kapsayan en yaygın kurumsal mimari çerçevelerinden biri.
  • Zachman Framework — mimariyi farklı perspektiflerden çeşitli boyutlarıyla sınıflandıran, 6×6 matris olarak sunulan kurumsal mimari artifaktları ontolojisi.

Analiz ve Geliştirme Süreçlerine Yaklaşımlar

  • Katı yaklaşım (Hard Systems) — önceden resmileştirilebilir hedefler ve gereksinimler ile «yukarıdan aşağıya» ayrıştırma ve tasarım öngören sistem analizi metodolojisi; net tanımlanmış görevler için etkilidir.
  • Yumuşak yaklaşım (Soft Systems) — belirsiz hedeflerin ve paydaşların çoklu bakış açılarının olduğu durumlar için uygulanan; sorunun anlaşılmasını ve istenen değişikliklerin uzlaştırılmasını amaçlayan sistem analizi metodolojisi.
  • SSM (Soft Systems Methodology) — Peter Checkland tarafından geliştirilen; rich picture, kök tanımlar ve CATWOE gibi araçları kullanan somut bir yumuşak sistem yaklaşımı metodolojisi.
  • Waterfall (şelale modeli) — aşamaların (analiz, tasarım, uygulama, test, devreye alma) bir önceki aşama tamamen bitmeden bir sonrakine geçilmeksizin sırasıyla yürütüldüğü klasik yazılım geliştirme metodolojisi.
  • Agile — iteratif geliştirmeye, değişimlere uyum sağlamaya, müşteriyle etkileşime ve sürekli değer teslimine odaklanan çevik yazılım geliştirme metodolojileri grubu.

Seçim Yöntemleri ve Tipik Hatalar

  • AHP (Analytic Hierarchy Process) — karmaşık sorunları yapılandırmaya ve alternatifleri bir kriter hiyerarşisine dayalı olarak değerlendirmeye olanak tanıyan çok kriterli seçim yöntemi.
  • Gold-plating («altın kaplama» sendromu) — paydaşların talep etmediği işlevlerin eklenmesinden kaynaklanan sistem analizi hatası; projenin kapsam ve karmaşıklığının artmasına yol açar.

Dış bağlantılar

  • ISO/IEC/IEEE 15288:2023 — System life cycle processes
  • ISO/IEC/IEEE 12207:2017 — Software life cycle processes
  • ISO/IEC/IEEE 29148:2018 — Requirements engineering
  • ISO/IEC/IEEE 42010:2022 — Architecture description
  • ISO/IEC 25010:2023 — Product quality model (SQuaRE)
  • ISO/IEC/IEEE 24748-2:2024 — Life cycle management — Guidelines for applying ISO/IEC/IEEE 15288
  • ISO/IEC/IEEE 15289:2019 — Content of life-cycle information items (documentation)
  • ISO/IEC/IEEE 42020:2019 — Architecture processes
  • ISO/IEC/IEEE 29119-1:2022 — Software testing — Part 1: General concepts
  • IEEE Std 1012-2024 — System, Software, and Hardware Verification and Validation
  • UML 2.5.1 — OMG Specification
  • BPMN 2.0.2 — OMG Specification
  • SysML v1.7 — OMG Specification
  • TOGAF Standard, 10th Edition — The Open Group
  • ArchiMate 3.2 — The Open Group
  • SEI ATAM — Architecture Tradeoff Analysis Method
  • NASA Systems Engineering Handbook, SP-2016-6105 Rev2 (PDF)
  • SWEBOK Guide v4.0a — IEEE Computer Society (PDF)
  • Guide to the Systems Engineering Body of Knowledge (SEBoK)
  • BABOK Guide v3 — IIBA
  • Google SRE Books — Official site
  • Microsoft Azure Well-Architected Framework — Official docs
  • Sistemik analiz basit bir dille. YouTube
  • IT'de sistem analizi basit bir dille. YouTube

Kaynakça

  • ISO/IEC/IEEE (2023). 15288: System Life Cycle Processes.
  • INCOSE (2023). INCOSE Systems Engineering Handbook, 5. baskı.
  • ISO/IEC/IEEE (2018). 29148: Systems and Software Engineering — Life Cycle Processes — Requirements Engineering.
  • IIBA (2015). A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), v3.
  • The Open Group (2022). The TOGAF® Standard, 10th Edition. Resmi ücretsiz sürüm.
  • OMG (2017). Unified Modeling Language (UML®) 2.5.1 Specification. PDF.
  • OMG (2014). Business Process Model and Notation (BPMN™) 2.0.2 Specification. PDF.
  • OMG (2024). Systems Modeling Language (SysML®) 1.7 Specification. PDF.
  • The Open Group (2022). ArchiMate® 3.2 Specification. Resmi ücretsiz indirme (lisans kapsamında).
  • Bass, L.; Clements, P.; Kazman, R. (2021). Software Architecture in Practice, 4. baskı.
  • Wiegers, K.; Beatty, J. (2013). Software Requirements, 3. baskı.
  • Rozanski, N.; Woods, E. (2012). Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives, 2. baskı.
  • Meadows, D. (2008). Thinking in Systems: A Primer.
  • Senge, P. M. (2006). The Fifth Discipline: The Art & Practice of the Learning Organization (rev. ed.).
  • Blanchard, B. S.; Fabrycky, W. J. (2010). Systems Engineering and Analysis, 5. baskı.
  • Robertson, J.; Robertson, S. (2012). Mastering the Requirements Process: Getting Requirements Right, 3. baskı.
  • van Lamsweerde, A. (2009). Requirements Engineering: From System Goals to UML Models to Software Specifications.
  • Hull, E.; Jackson, K.; Dick, J. (2017). Requirements Engineering, 4. baskı.
  • Kendall, K. E.; Kendall, J. E. (2023). Systems Analysis and Design, 11. baskı.
  • Dennis, A.; Wixom, B. H.; Tegarden, D. (2021). Systems Analysis and Design: An Object-Oriented Approach with UML, 8. baskı.
  • Satzinger, J. W.; Jackson, R. B.; Burd, S. D. (2015). Systems Analysis and Design in a Changing World, 7. baskı.
  • Fowler, M. (2003). UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3. baskı.
  • Delligatti, L. (2013). SysML Distilled: A Brief Guide to the Systems Modeling Language.
  • Silver, B. (2011). BPMN Method and Style, 2. baskı.
  • Lankhorst, M. et al. (2017). Enterprise Architecture at Work: Modelling, Communication and Analysis, 4. baskı.
  • Richards, M.; Ford, N. (2020). Fundamentals of Software Architecture.
  • Fairbanks, G. (2010). Just Enough Software Architecture: A Risk-Driven Approach.
  • Keeling, M. (2017). Design It!: From Programmer to Software Architect.
  • Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software.
  • Vernon, V. (2013). Implementing Domain-Driven Design.
  • Brandolini, A. (2018). Introducing EventStorming: An Act of Deliberate Collective Learning.
  • Simsion, G.; Witt, G. (2015). Data Modeling Essentials, 4. baskı.
  • Silverston, L. (2008–2009). The Data Model Resource Book, Vols. 1–3 (rev. eds.).
  • Keeney, R. L.; Raiffa, H. (1993). Decisions with Multiple Objectives: Preferences and Value Trade-Offs, 2. baskı.
  • Saaty, T. L. (1980). The Analytic Hierarchy Process; (1990) Decision Making for Leaders.

Notlar

  1. ↑ 1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 1.10 1.11 1.12 IEEE Computer Society (2025). Guide to the Software Engineering Body of Knowledge (SWEBOK), v4.0a. Requirements Engineering: elicitation techniques. https://ieeecs-media.computer.org/media/education/swebok/swebok-v4.pdf
  2. ↑ Zowghi, D.; Coulin, C. (2005/2014). Requirements Elicitation: A Survey of Techniques, Approaches, and Tools. https://eecs481.org/readings/requirements.pdf
  3. ↑ 3.00 3.01 3.02 3.03 3.04 3.05 3.06 3.07 3.08 3.09 3.10 3.11 3.12 ISO/IEC/IEEE 29148 (2011/2018). Systems and software engineering — Requirements engineering. ISO overview page: «Defines the construct of a good requirement…». https://www.iso.org/standard/45171.html
  4. ↑ 4.0 4.1 4.2 NASA (2020). NPR 7123.1C — Systems Engineering Processes and Requirements. Определение «well-formed (clear and unambiguous), complete, consistent, individually verifiable and traceable». https://nodis3.gsfc.nasa.gov/displayAll.cfm?Internal_ID=N_PR_7123_001C_&page_name=all
  5. ↑ GMU (George Mason University). IEEE Software Requirements Specification Template (SRS). https://cs.gmu.edu/~rpettit/files/project/SRS-template.doc
  6. ↑ Westfall, L. (Cal Poly, .edu). The What, Why, Who, When and How of Software Requirements (упоминает URS). https://users.csc.calpoly.edu/~csturner/courses/300f06/readings/%5B3%5D_%20The_Why_What_Who_When_and_How_of_Software_Requirements.pdf
  7. ↑ Stanford University IT (.edu). Functional Specification Document Template. https://uit.stanford.edu/sites/default/files/2017/08/30/Functional%20Specification%20Document%20Template.docx
  8. ↑ Penn State (.edu). Elements of a Use Case Diagram. https://www.e-education.psu.edu/geog468/l8_p4.html
  9. ↑ UC Irvine (.edu). Data Flow Diagram. https://www.security.uci.edu/program/risk-assessment/data-flow-diagram/
  10. ↑ ISO/IEC/IEEE 42010 (2011/2022). Architecture description — требования к описанию архитектуры и точкам зрения. https://standards.ieee.org/ieee/42010/5334/
  11. ↑ Cornell University (.edu). CS 5150 — Feasibility Studies. https://www.cs.cornell.edu/courses/cs5150/2015fa/slides/C1-feasibility.pdf
  12. ↑ Carnegie Mellon SEI. Architecture Tradeoff Analysis Method (ATAM) — overview. https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/
  13. ↑ Microsoft Azure Architecture Center. Architecture styles: microservices — benefits & complexity. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/
  14. ↑ Google Cloud. What Is Microservices Architecture? — Monolithic vs. microservices (обзор). https://cloud.google.com/learn/what-is-microservices-architecture
  15. ↑ NASA (2023). Requirements Management — Traceability, Bidirectional traceability (definitions). https://www.nasa.gov/reference/6-2-requirements-management/
  16. ↑ McKinsey (2012). Delivering large-scale IT projects on time, on budget, and on value. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value
  17. ↑ University of Cambridge, IfM. Soft Systems Methodology (SSM) — CATWOE, 3Es. https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/
  18. ↑ Lancaster University (ePrints). Soft Systems Methodology and root definitions. https://eprints.lancs.ac.uk/id/eprint/48770/1/Document.pdf
  19. ↑ University of Cambridge, IfM. Soft Systems Methodology (SSM). https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/
  20. ↑ UCL Discovery (.ac.uk). M. Haklay. Soft System Methodology (SSM). https://discovery.ucl.ac.uk/1296/1/paper13.pdf
  21. ↑ IEEE Std 1320.1-1998 (R2004). Functional Modeling Language — Syntax and Semantics for IDEF0. https://standards.ieee.org/ieee/1320.1/2003/
  22. ↑ ISO/IEC/IEEE 31320-1:2012. IDEF0: Function Modeling. https://cdn.standards.iteh.ai/samples/60615/9c848e7a1bc54042b774b3cb050872e7/ISO-IEC-IEEE-31320-1-2012.pdf
  23. ↑ University of Washington (.edu). UML Class Diagrams / UML overview (course material). https://courses.cs.washington.edu/courses/cse403/16au/lectures/L07.pdf
  24. ↑ JHU/APL (.edu). Modeling with SysML — tutorial. https://www.jhuapl.edu/sites/default/files/2023-03/ModelingwithSysMLTutorial.pdf
  25. ↑ MIT OCW (.edu). O. de Weck. Introduction to Systems Modeling Languages (incl. SysML, MBSE). https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/23fea897f48d11f45593fa4be698d749_MIT16_842F15_Ses3_sysmodlg.pdf
  26. ↑ IBM. What is Business Process Modeling and Notation (BPMN)?. https://www.ibm.com/think/topics/bpmn
  27. ↑ IBM Docs. Business Process Modeling Notation (BPMN) model. https://www.ibm.com/docs/en/iis/11.5.0?topic=types-business-process-modeling-notation-bpmn-model
  28. ↑ IEEE/ISO/IEC 29148:2018. Systems and software engineering — Requirements engineering (overview). https://standards.ieee.org/ieee/29148/6937/
  29. ↑ King’s College London (.ac.uk). What is MoSCoW prioritization?. https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/
  30. ↑ T. L. Saaty. How to Make a Decision: The Analytic Hierarchy Process. Interfaces 24(6), 1994. https://pubsonline.informs.org/doi/10.1287/inte.24.6.19
  31. ↑ Microsoft Learn (Azure Boards). Best practices for Agile project management — Refine each backlog. https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management
  32. ↑ MIT OCW (.edu). V-Model — Fundamentals of Systems Engineering. https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/resources/v-model/
  33. ↑ Carnegie Mellon SEI (.edu). Architecture Tradeoff Analysis Method (ATAM) — overview. https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/
  34. ↑ Microsoft Azure Architecture Center. Architecture styles. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/
  35. ↑ Kazman, R.; Klein, M.; Clements, P. ATAM: Method for Architecture Evaluation. CMU/SEI Technical Report, 2000. https://www.sei.cmu.edu/documents/629/2000_005_001_13706.pdf
  36. ↑ 36.0 36.1 36.2 36.3 The Open Group. Introduction — The TOGAF® Standard. https://www.togaf.org/chap01.html
  37. ↑ Microsoft Azure Architecture Center. Event-Driven Architecture style. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven
  38. ↑ Jonkers, H. et al. ArchiMate® and the TOGAF® Framework. The Open Group (white paper). https://pubs.opengroup.org/onlinepubs/7698909899/toc.pdf
  39. ↑ Estrem, W. Building Blocks Revisited. The Open Group (presentation). https://archive.opengroup.org/public/member/proceedings/q411b/presentations/Estrem%20-%20Building%20Blocks%20Revisted.pdf
  40. ↑ The Open Group. Architecture Principles. https://pubs.opengroup.org/onlinepubs/7499919799/toc.pdf
  41. ↑ The Open Group. IT Architecture Compliance. https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm
  42. ↑ The TOGAF® Standard, Version 9.2 (спецификация). The Open Group. https://university.sk/wp-content/uploads/2020/01/TOGAF_v9_2_specifikacia.pdf
  43. ↑ Engelsman, W.; van Sinderen, M. Supporting Requirements Management in TOGAF and ArchiMate. The Open Group (white paper). https://pubs.opengroup.org/onlinepubs/7698999899/toc.pdf
  44. ↑ Zachman, J. A. A Framework for Information Systems Architecture. IBM Systems Journal, 26(3), 276–292, 1987. https://doi.org/10.1147/sj.263.0276
  45. ↑ MIT CISR. Classic Topics — Enterprise Architecture (определение EA как «organizing logic for business process and IT capabilities…»). https://cisr.mit.edu/content/classic-topics-enterprise-architecture
  46. ↑ The Open Group. IT Architecture Compliance. https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm
  47. ↑ Royce, W. W. (1970). Managing the Development of Large Software Systems. IEEE WESCON. Репринт (PDF): https://www.praxisframework.org/files/royce1970.pdf
  48. ↑ Defense Acquisition University. System Requirements Review (SRR) — Acquipedia. https://aaf.dau.edu/acquipedia/article/system-requirements-review-srr/
  49. ↑ NASA (2023). Requirements Management — baseline, change control (CCB). https://www.nasa.gov/reference/6-2-requirements-management/
  50. ↑ Microsoft Learn (Azure Boards). Best practices for Agile project management — Refine each backlog. https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management
  51. ↑ MSDN Magazine (Microsoft). BDD Primer: Behavior‑Driven Development with SpecFlow. https://learn.microsoft.com/en-us/archive/msdn-magazine/2010/december/msdn-magazine-bdd-primer-behavior-driven-development-with-specflow-and-watin
  52. ↑ Microsoft Learn. End‑to‑end traceability in Azure DevOps. https://learn.microsoft.com/en-us/azure/devops/cross-service/end-to-end-traceability
  53. ↑ Google SRE. Service Level Objectives; Error Budget Policy. https://sre.google/sre-book/service-level-objectives/ ; https://sre.google/workbook/error-budget-policy/
  54. ↑ Microsoft Learn. Azure Monitor — Overview. https://learn.microsoft.com/en-us/azure/azure-monitor/fundamentals/overview
  55. ↑ AWS Whitepaper. Blue/Green Deployments on AWS. https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/welcome.html
  56. ↑ Microsoft Learn. Manage change — track, triage, and implement change requests. https://learn.microsoft.com/en-us/azure/devops/cross-service/manage-change
  57. ↑ Microsoft Learn (Azure Boards). Backlogs overview — create and manage your product backlog. https://learn.microsoft.com/en-us/azure/devops/boards/backlogs/backlogs-overview
  58. ↑ Microsoft Learn (Azure Test Plans). What is Azure Test Plans?. https://learn.microsoft.com/en-us/azure/devops/test/overview
  59. ↑ MSDN Magazine. Behavior‑Driven Design with SpecFlow. https://learn.microsoft.com/en-us/archive/msdn-magazine/2013/july/data-points-behavior-driven-design-with-specflow
  60. ↑ IBM. MTTR vs. MTBF: What’s the difference?. https://www.ibm.com/think/topics/mttr-vs-mtbf
  61. ↑ Google Cloud. Google Cloud Observability. https://cloud.google.com/products/observability
  62. ↑ IEEE Std 830‑1998. IEEE Recommended Practice for Software Requirements Specifications (исторический стандарт). Учебная копия (PDF): https://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf
  63. ↑ 63.0 63.1 63.2 63.3 NASA. Systems Engineering Handbook (NASA/SP‑2016‑6105 Rev2). https://www.nasa.gov/wp-content/uploads/2018/09/nasa_systems_engineering_handbook_0.pdf
  64. ↑ 64.0 64.1 NASA (2023). Requirements Management — traceability, baseline, CCB. https://www.nasa.gov/reference/6-2-requirements-management/
  65. ↑ King’s College London (.ac.uk). What is MoSCoW prioritization?. https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/
  66. ↑ Saaty, T. L. (1994). How to Make a Decision: The Analytic Hierarchy Process. Interfaces 24(6), 19–43. https://doi.org/10.1287/inte.24.6.19
  67. ↑ SEI / CMMI Institute. Capability Maturity Model Integration (CMMI) — Overview. https://www.sei.cmu.edu/cmmi/
  68. ↑ NASA Langley. What is Formal Methods?; NASA‑GB‑002‑95 Guidebook. https://shemesh.larc.nasa.gov/fm/fm-what.html ; https://ntrs.nasa.gov/api/citations/19980228002/downloads/19980228002.pdf
  69. ↑ 69.0 69.1 SEI (CMU). Common Testing Problems: Pitfalls to Prevent and Mitigate (о типичных проблемах требований/трассируемости). https://www.sei.cmu.edu/blog/common-testing-problems-pitfalls-to-prevent-and-mitigate/
  70. ↑ 70.0 70.1 70.2 70.3 70.4 70.5 70.6 70.7 NIST (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100‑1. https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf
  71. ↑ 71.0 71.1 71.2 71.3 71.4 71.5 U.S. DoD CIO (2021). DoD Enterprise DevSecOps Reference Design. https://dodcio.defense.gov/Portals/0/Documents/Library/DevSecOpsReferenceDesign.pdf
  72. ↑ Профессиональный стандарт «Системный аналитик» (приказ Минтруда РФ от 27.04.2023 № 367н).
Retrieved from "https://systems-analysis.info/int/index.php?title=BT%27de_Sistem_Analizi&oldid=702"