Yazılım Mühendisliği - Hızlı Kılavuz

Önce yazılım mühendisliğinin ne anlama geldiğini anlayalım. Terim, yazılım ve mühendislik olmak üzere iki kelimeden oluşur.

Software bir program kodundan daha fazlasıdır. Bir program, bazı hesaplama amaçlarına hizmet eden çalıştırılabilir bir koddur. Yazılım, çalıştırılabilir programlama kodu, ilgili kitaplıklar ve belgelerin bir koleksiyonu olarak kabul edilir. Yazılım, belirli bir gereksinim için yapıldığında denirsoftware product.

Engineering Öte yandan, iyi tanımlanmış, bilimsel ilkeler ve yöntemler kullanarak ürün geliştirmekle ilgilidir.

Software engineeringiyi tanımlanmış bilimsel ilkeler, yöntemler ve prosedürler kullanılarak yazılım ürününün geliştirilmesi ile ilgili bir mühendislik dalıdır. Yazılım mühendisliğinin sonucu, verimli ve güvenilir bir yazılım ürünüdür.

Tanımlar

IEEE, yazılım mühendisliğini şu şekilde tanımlar:

(1) Yazılımın geliştirilmesi, çalıştırılması ve bakımı için sistematik, disiplinli, ölçülebilir bir yaklaşımın uygulanması; yani mühendisliğin yazılıma uygulanması.

(2) Yukarıdaki açıklamadaki gibi yaklaşımların incelenmesi.

Alman bilgisayar bilimcisi Fritz Bauer, yazılım mühendisliğini şu şekilde tanımlıyor:

Yazılım mühendisliği, güvenilir ve gerçek makinelerde verimli çalışan, ekonomik bir yazılım elde etmek için sağlam mühendislik ilkelerinin oluşturulması ve kullanılmasıdır.

Yazılım Evrimi

Yazılım mühendisliği ilkelerini ve yöntemlerini kullanarak bir yazılım ürünü geliştirme süreci şu şekilde anılır: software evolution. Bu, beklenen gereksinimleri karşılayan istenen yazılım ürünü geliştirilinceye kadar yazılımın ilk geliştirilmesini, bakımını ve güncellemelerini içerir.

Evrim, ihtiyaç toplama sürecinden başlar. Bundan sonra geliştiriciler, amaçlanan yazılımın bir prototipini oluşturur ve kullanıcılara, yazılım ürünü geliştirmenin erken aşamasında geri bildirimlerini almak için gösterir. Kullanıcılar, birkaç ardışık güncelleme ve bakımın da değişmeye devam ettiği değişiklikler önerir. Bu işlem, istenen yazılım elde edilene kadar orijinal yazılıma değişir.

Kullanıcının elinde yazılım istediği halde gelişen teknoloji ve değişen gereksinimler yazılım ürününü buna göre değişmeye zorlamaktadır. Yazılımı sıfırdan yeniden oluşturmak ve gereksinimle bire bir gitmek mümkün değildir. Tek uygulanabilir ve ekonomik çözüm, mevcut yazılımı en son gereksinimleri karşılayacak şekilde güncellemektir.

Yazılım Evrim Kanunları

Lehman, yazılım evrimi için yasalar verdi. Yazılımı üç farklı kategoriye ayırdı:

• S-type (static-type) - Bu, kesinlikle tanımlanmış spesifikasyonlara ve çözümlere göre çalışan bir yazılımdır . Çözüm ve buna ulaşma yöntemi, kodlamadan hemen önce anlaşılır. S-tipi yazılım en az değişikliğe maruz kalır, bu nedenle bu en basit olanıdır. Örneğin, matematiksel hesaplama için hesap makinesi programı.
• P-type (practical-type) - Bu, bir dizi prosedür içeren bir yazılımdır . Bu, prosedürlerin tam olarak neler yapabileceği ile tanımlanır. Bu yazılımda teknik özellikler açıklanabilir ancak çözüm hemen belli değildir. Örneğin, oyun yazılımı.
• E-type (embedded-type) - Bu yazılım, gerçek dünya ortamının gereği olarak yakından çalışır . Bu yazılım, gerçek dünyadaki durumlarda kanunlarda, vergilerde vb. Çeşitli değişiklikler olduğu için yüksek derecede evrim geçirmiştir. Örneğin, Çevrimiçi ticaret yazılımı.

E-Type yazılım evrimi

Lehman, E-Type yazılım evrimi için sekiz yasa verdi -

• Continuing change - Bir E-tipi yazılım sistemi gerçek dünyadaki değişikliklere uyum sağlamaya devam etmelidir, aksi takdirde giderek daha az kullanışlı hale gelir.
• Increasing complexity - E-tipi bir yazılım sistemi geliştikçe karmaşıklığı, onu korumak veya azaltmak için bir çalışma yapılmadıkça artma eğilimindedir.
• Conservation of familiarity - Sistemdeki değişiklikleri uygulamak için yazılıma aşinalık veya nasıl geliştirildiği, neden bu şekilde geliştirildiği vb. Her ne pahasına olursa olsun korunmalıdır.
• Continuing growth- Bazı iş sorunlarını çözmeyi amaçlayan bir E-tipi sistem için, işin yaşam tarzı değişikliklerine göre değişiklikleri uygulama boyutu büyüyor.
• Reducing quality - E-tipi bir yazılım sistemi, titizlikle muhafaza edilmedikçe ve değişen operasyonel ortama adapte edilmedikçe kalitesi düşer.
• Feedback systems- E-tipi yazılım sistemleri çok döngülü, çok seviyeli geri bildirim sistemlerini oluşturur ve başarılı bir şekilde değiştirilmek veya iyileştirilmek için bu şekilde ele alınmalıdır.
• Self-regulation - E-tipi sistem evrim süreçleri, ürün ve süreç ölçülerinin normale yakın dağılımı ile kendi kendini düzenler.
• Organizational stability - Gelişen bir E-tipi sistemdeki ortalama etkin küresel aktivite oranı, ürünün kullanım ömrü boyunca değişmez.

Yazılım Paradigmaları

Yazılım paradigmaları, yazılımı tasarlarken atılan yöntem ve adımlara atıfta bulunur. Bugün önerilen ve işleyen birçok yöntem var, ancak bu paradigmaların yazılım mühendisliğinde nerede durduğunu görmemiz gerekiyor. Bunlar, her biri diğerinde yer alsa da çeşitli kategoriler halinde birleştirilebilir:

Programlama paradigması, ayrıca Yazılım geliştirme paradigmasının bir alt kümesi olan Yazılım tasarım paradigmasının bir alt kümesidir.

Yazılım Geliştirme Paradigması

Bu Paradigma, yazılımın geliştirilmesiyle ilgili tüm mühendislik kavramlarının uygulandığı yazılım mühendisliği paradigmaları olarak bilinir. Yazılım ürününün oluşturulmasına yardımcı olan çeşitli araştırmaları ve gereksinim toplamayı içerir. Bu oluşmaktadır -

• Şartlı toplantı
• Yazılım Tasarımı
• Programming

Yazılım Tasarım Paradigması

Bu paradigma, Yazılım Geliştirmenin bir parçasıdır ve şunları içerir:

• Design
• Maintenance
• Programming

Programlama Paradigması

Bu paradigma, yazılım geliştirmenin programlama yönü ile yakından ilgilidir. Bu içerir -

• Coding
• Testing
• Integration

Yazılım Mühendisliği İhtiyacı

Yazılım mühendisliği ihtiyacı, kullanıcı gereksinimlerindeki ve yazılımın üzerinde çalıştığı ortamdaki daha yüksek değişim oranlarından kaynaklanmaktadır.

• Large software - Aynı şekilde, bir duvar inşa etmek bir ev ya da binaya göre daha kolaydır, çünkü yazılımın boyutu büyüdükçe, mühendislik ona bilimsel bir süreç vermek için adım atmak zorunda kalır.
• Scalability- Yazılım süreci bilimsel ve mühendislik kavramlarına dayalı olmasaydı, yeni yazılımı yeniden yaratmak, mevcut olanı ölçeklendirmekten daha kolay olurdu.
• Cost- Donanım endüstrisi becerilerini gösterdikçe ve büyük üretim, bilgisayar ve elektronik donanım fiyatlarını düşürdü. Ancak uygun süreç uyarlanmazsa yazılım maliyeti yüksek kalır.
• Dynamic Nature- Yazılımın sürekli büyüyen ve uyarlanan doğası, büyük ölçüde kullanıcının çalıştığı ortama bağlıdır. Yazılımın doğası sürekli değişiyorsa, mevcut yazılımda yeni geliştirmelerin yapılması gerekir. Burası yazılım mühendisliğinin iyi bir rol oynadığı yerdir.
• Quality Management- Daha iyi yazılım geliştirme süreci, daha iyi ve kaliteli yazılım ürünü sağlar.

İyi bir yazılımın özellikleri

Bir yazılım ürünü ne sunduğuna ve ne kadar iyi kullanılabileceğine göre değerlendirilebilir. Bu yazılım aşağıdaki gerekçeleri karşılamalıdır:

• Operational
• Transitional
• Maintenance

İyi tasarlanmış ve hazırlanmış yazılımın aşağıdaki özelliklere sahip olması beklenmektedir:

Operasyonel

Bu bize yazılımın operasyonlarda ne kadar iyi çalıştığını gösterir. Aşağıdakiler üzerinde ölçülebilir:

• Budget
• Usability
• Efficiency
• Correctness
• Functionality
• Dependability
• Security
• Safety

Geçiş

Bu husus, yazılım bir platformdan diğerine taşındığında önemlidir:

• Portability
• Interoperability
• Reusability
• Adaptability

Bakım

Bu özellik, bir yazılımın sürekli değişen ortamda kendini koruma yeteneklerine ne kadar sahip olduğunu özetlemektedir:

• Modularity
• Maintainability
• Flexibility
• Scalability

Kısacası, Yazılım mühendisliği, verimli, dayanıklı, ölçeklenebilir, bütçe dahilinde ve zamanında yazılım ürünleri üretmek için gereken iyi tanımlanmış mühendislik kavramlarını kullanan bir bilgisayar bilimi dalıdır.

Yazılım Geliştirme Yaşam Döngüsü, kısaca SDLC, amaçlanan yazılım ürününü geliştirmek için yazılım mühendisliğinde iyi tanımlanmış, yapılandırılmış bir aşamalar dizisidir.

SDLC Faaliyetleri

SDLC, bir yazılım ürününü verimli bir şekilde tasarlamak ve geliştirmek için izlenecek bir dizi adım sağlar. SDLC çerçevesi aşağıdaki adımları içerir:

İletişim

Bu, kullanıcının istediği bir yazılım ürünü talebini başlattığı ilk adımdır. Servis sağlayıcıyla iletişime geçer ve şartları görüşmeye çalışır. Hizmet veren kuruluşa talebini yazılı olarak iletir.

Şartlı toplantı

Bu adım ileriye doğru yazılım geliştirme ekibi projeyi devam ettirmek için çalışır. Ekip, sorun alanından çeşitli paydaşlarla tartışmalar yapar ve gereksinimleri hakkında olabildiğince fazla bilgi ortaya çıkarmaya çalışır. Gereksinimler tasarlanır ve kullanıcı gereksinimleri, sistem gereksinimleri ve işlevsel gereksinimler olarak ayrılır. Gereksinimler, verilen bir dizi uygulama kullanılarak toplanır -

• mevcut veya eski sistem ve yazılımı incelemek,
• kullanıcılar ve geliştiricilerle görüşmeler yapmak,
• veritabanına atıfta bulunarak veya
• anketlerden cevapların toplanması.

Fizibilite çalışması

İhtiyaç toplandıktan sonra ekip, kaba bir yazılım süreci planı çıkarır. Bu aşamada ekip, kullanıcının tüm gereksinimlerini karşılayacak bir yazılımın yapılıp yapılamayacağını ve yazılımın artık kullanışlı olmaması olasılığının olup olmadığını analiz eder. Projenin kuruluş için finansal, pratik ve teknolojik olarak uygun olup olmadığı ortaya çıkar. Geliştiricilerin bir yazılım projesinin fizibilitesini sonuçlandırmasına yardımcı olan birçok algoritma mevcuttur.

Sistem Analizi

Bu adımda geliştiriciler planlarının bir yol haritasını belirler ve projeye uygun en iyi yazılım modelini ortaya çıkarmaya çalışırlar. Sistem analizi, yazılım ürün sınırlamalarının anlaşılması, sistemle ilgili problemlerin veya mevcut sistemlerde önceden yapılacak değişikliklerin anlaşılması, projenin organizasyon ve personel üzerindeki etkisinin belirlenmesi ve ele alınması vb. İçerir. Proje ekibi projenin kapsamını analiz eder ve programı planlar ve buna göre kaynaklar.

Yazılım Tasarımı

Bir sonraki adım, masadaki tüm gereksinimler ve analiz bilgisini aşağı çekmek ve yazılım ürününü tasarlamaktır. Kullanıcılardan gelen girdiler ve ihtiyaç toplama aşamasında toplanan bilgiler bu adımın girdileridir. Bu adımın çıktısı iki tasarım şeklinde gelir; mantıksal tasarım ve fiziksel tasarım. Mühendisler meta veri ve veri sözlükleri, mantıksal diyagramlar, veri akış diyagramları ve bazı durumlarda sözde kodlar üretir.

Kodlama

Bu adım aynı zamanda programlama aşaması olarak da bilinir. Yazılım tasarımının uygulanması, program kodunun uygun programlama dilinde yazılması ve hatasız çalıştırılabilir programların verimli bir şekilde geliştirilmesi açısından başlar.

Test yapmak

Bir tahmin, tüm yazılım geliştirme sürecinin% 50'sinin test edilmesi gerektiğini söylüyor. Hatalar, yazılımı kritik seviyeden kendi kaldırmasına kadar bozabilir. Yazılım testleri, geliştiriciler tarafından kodlanırken yapılır ve modül testi, program testi, ürün testi, kurum içi test ve kullanıcı sonunda ürünü test etme gibi çeşitli kod seviyelerinde uzmanlar tarafından test edilerek kapsamlı testler yapılır. Hataların erken keşfedilmesi ve giderilmesi, güvenilir yazılımın anahtarıdır.

Entegrasyon

Yazılımın kitaplıklar, veritabanları ve diğer program (lar) ile entegre edilmesi gerekebilir. SDLC'nin bu aşaması, yazılımın dış dünya varlıkları ile entegrasyonuyla ilgilidir.

Uygulama

Bu, yazılımı kullanıcı makinelerine yüklemek anlamına gelir. Bazen, yazılımın kullanıcı tarafında kurulum sonrası yapılandırmalara ihtiyacı vardır. Yazılım, taşınabilirlik ve uyarlanabilirlik açısından test edilir ve entegrasyonla ilgili sorunlar uygulama sırasında çözülür.

Operasyon ve bakım

Bu aşama, yazılımın çalışmasını daha fazla verimlilik ve daha az hata açısından doğrular. Gerekirse kullanıcılar, yazılımın nasıl çalıştırılacağı ve yazılımın nasıl çalışır durumda tutulacağı konusunda eğitim alır veya bu belgelerle yardım edilir. Yazılımın bakımı, kullanıcı son ortamında veya teknolojide meydana gelen değişikliklere göre kod güncellenerek zamanında yapılmaktadır. Bu aşama, gizli hatalardan ve gerçek dünyadaki tanımlanamayan sorunlardan kaynaklanan zorluklarla karşılaşabilir.

Mevzuat

Zaman geçtikçe, yazılım performans cephesinde düşebilir. Tamamen modası geçmiş olabilir veya yoğun bir yükseltme gerektirebilir. Bu nedenle, sistemin büyük bir bölümünü ortadan kaldırmak için acil bir ihtiyaç ortaya çıkmaktadır. Bu aşama, verilerin ve gerekli yazılım bileşenlerinin arşivlenmesini, sistemin kapatılmasını, elden çıkarma faaliyetinin planlanmasını ve uygun sistem sonu zamanında sistemi sonlandırmayı içerir.

Yazılım Geliştirme Paradigması

Yazılım geliştirme paradigması, geliştiricinin yazılımı geliştirmek için bir strateji seçmesine yardımcı olur. Bir yazılım geliştirme paradigmasının, açıkça ifade edilen ve yazılım geliştirme yaşam döngüsünü tanımlayan kendi araçları, yöntemleri ve prosedürleri vardır. Yazılım geliştirme paradigmalarından veya süreç modellerinden birkaçı şu şekilde tanımlanır:

Şelale Modeli

Şelale modeli, yazılım geliştirme paradigmasının en basit modelidir. SDLC'nin tüm aşamalarının birbiri ardına doğrusal bir şekilde çalışacağını söylüyor. Yani, ilk aşama bittiğinde yalnızca ikinci aşama başlayacaktır ve bu böyle devam edecektir.

Bu model, her şeyin bir önceki aşamada planlandığı gibi kusursuz bir şekilde yürütüldüğünü ve gerçekleştiğini ve bir sonraki aşamada ortaya çıkabilecek geçmiş sorunları düşünmeye gerek olmadığını varsayar. Önceki adımda kalan bazı sorunlar varsa bu model sorunsuz çalışmaz. Modelin sıralı yapısı, geri dönmemize ve eylemlerimizi geri almamıza veya yeniden yapmamıza izin vermez.

Bu model, geliştiriciler geçmişte benzer bir yazılım tasarlayıp geliştirdiğinde ve tüm alanlarının farkında olduğunda en uygunudur.

Yinelemeli Model

Bu model, yinelemelerde yazılım geliştirme sürecine öncülük eder. Geliştirme sürecini, SDLC sürecinin her döngüsünden sonra her adımı tekrarlayarak döngüsel bir şekilde yansıtır.

Yazılım önce çok küçük ölçekte geliştirilir ve dikkate alınan tüm adımlar takip edilir. Ardından, her bir sonraki yinelemede, daha fazla özellik ve modül tasarlanır, kodlanır, test edilir ve yazılıma eklenir. Her döngü, kendi içinde tamamlanan ve bir öncekinden daha fazla özellik ve kabiliyete sahip bir yazılım üretir.

Her yinelemeden sonra, yönetim ekibi risk yönetimi üzerinde çalışabilir ve bir sonraki yinelemeye hazırlanabilir. Bir döngü, tüm yazılım sürecinin küçük bir bölümünü içerdiğinden, geliştirme sürecini yönetmek daha kolaydır ancak daha fazla kaynak tüketir.

Spiral Modeli

Spiral model, hem yinelemeli modelin hem de SDLC modelinin bir kombinasyonudur. Tek bir SDLC modeli seçip onu döngüsel süreçle (yinelemeli model) birleştiriyormuşsunuz gibi görülebilir.

Bu model, çoğu diğer model tarafından genellikle fark edilmeyen riski dikkate alır. Model, bir yinelemenin başlangıcında yazılımın hedeflerini ve kısıtlamalarını belirlemekle başlar. Sonraki aşama, yazılımın prototipini oluşturmaktır. Bu, risk analizini içerir. Ardından yazılımı oluşturmak için bir standart SDLC modeli kullanılır. Bir sonraki iterasyon planının dördüncü aşamasında hazırlanır.

V - model

Şelale modelinin en büyük dezavantajı, bir sonraki aşamaya ancak önceki aşama bittiğinde geçmemiz ve sonraki aşamalarda bir şey yanlış bulunursa geri dönme şansımızın olmamasıdır. V-Modeli, yazılımın her aşamada tersine test edilmesine imkan sağlar.

Her aşamada, ürünü o aşamanın ihtiyacına göre doğrulamak ve doğrulamak için test planları ve test senaryoları oluşturulur. Örneğin, gereksinim toplama aşamasında test ekibi, gereksinimlere uygun olarak tüm test senaryolarını hazırlar. Daha sonra, ürün geliştirildiğinde ve teste hazır olduğunda, bu aşamadaki test durumları, yazılımı bu aşamadaki gereksinimlere yönelik geçerliliğine karşı doğrular.

Bu, hem doğrulama hem de doğrulamanın paralel ilerlemesini sağlar. Bu model aynı zamanda doğrulama ve doğrulama modeli olarak da bilinir.

Büyük Patlama Modeli

Bu model, formundaki en basit modeldir. Çok az planlama, çok sayıda programlama ve çok fazla fon gerektirir. Bu model, evrenin büyük patlaması etrafında kavramsallaştırılmıştır. Bilim adamlarının söylediği gibi, büyük patlamadan sonra birçok galaksi, gezegen ve yıldız sadece bir olay olarak evrimleşti. Aynı şekilde, çok sayıda programlama ve fonu bir araya getirirsek, en iyi yazılım ürününü elde edebilirsiniz.

Bu model için çok az miktarda planlama gereklidir. Herhangi bir süreci takip etmez veya bazen müşteri gereksinimlerden ve gelecekteki ihtiyaçlardan emin olmaz. Bu nedenle, girdi gereksinimleri keyfidir.

Bu model, büyük yazılım projeleri için uygun değil, öğrenme ve deneme için iyidir.

SDLC ve çeşitli modelleri hakkında derinlemesine bir okuma için burayı tıklayın.

Yazılım geliştirmeyle uğraşan bir BT şirketinin iş modeli iki bölüme ayrılabilir:

• Yazılım Oluşturma
• Yazılım Proje Yönetimi

Bir proje, bir hedefe ulaşmak için yapılan çeşitli işlemlerin bir toplamı olan iyi tanımlanmış bir görevdir (örneğin, yazılım geliştirme ve teslimat). Bir Proje şu şekilde karakterize edilebilir:

• Her projenin kendine özgü ve farklı bir hedefi olabilir.
• Proje rutin bir faaliyet veya günlük işlemler değildir.
• Proje, bir başlangıç ​​ve bitiş zamanıyla birlikte gelir.
• Proje, amacına ulaşıldığında sona erer, bu nedenle bir kuruluşun ömrü boyunca geçici bir aşamadır.
• Proje, zaman, insan gücü, finansman, malzeme ve bilgi bankası açısından yeterli kaynaklara ihtiyaç duyar.

Yazılım Projesi

Bir Yazılım Projesi, istenen yazılım ürününü elde etmek için belirli bir süre içinde yürütme metodolojilerine göre yürütülen, gereksinim toplamadan test ve bakıma kadar yazılım geliştirme sürecinin eksiksiz prosedürüdür.

Yazılım proje yönetimi ihtiyacı

Yazılımın soyut bir ürün olduğu söyleniyor. Yazılım geliştirme, dünya ticaretinde tamamen yeni bir akımdır ve yazılım ürünleri oluşturmada çok az deneyim vardır. Çoğu yazılım ürünü, müşterinin gereksinimlerine uyacak şekilde özel olarak üretilir. En önemlisi, temeldeki teknolojinin o kadar sık ​​ve hızlı değişip gelişmesidir ki, bir ürünün deneyimi diğerine uygulanamayabilir. Tüm bu tür iş ve çevresel kısıtlamalar yazılım geliştirmede risk getirir, bu nedenle yazılım projelerini verimli bir şekilde yönetmek çok önemlidir.

Yukarıdaki görüntü, yazılım projeleri için üçlü kısıtlamaları göstermektedir. Maliyeti müşterinin bütçe kısıtlaması dahilinde tutarak kaliteli ürün sunmak ve projeyi planlandığı gibi teslim etmek yazılım organizasyonunun önemli bir parçasıdır. Bu üçlü sınırlama üçgenini etkileyebilecek hem iç hem de dış birkaç faktör vardır. Üç faktörden herhangi biri diğer ikisini ciddi şekilde etkileyebilir.

Bu nedenle, kullanıcı gereksinimlerinin yanı sıra bütçe ve zaman kısıtlamalarını da dahil etmek için yazılım proje yönetimi çok önemlidir.

Yazılım Proje Yöneticisi

Yazılım proje yöneticisi, yazılım projesini yürütme sorumluluğunu üstlenen kişidir. Yazılım proje yöneticisi, yazılımın geçeceği SDLC'nin tüm aşamalarının tamamen farkındadır. Proje yöneticisi nihai ürünün üretimine asla doğrudan dahil olamaz, ancak üretimle ilgili faaliyetleri kontrol eder ve yönetir.

Bir proje yöneticisi, geliştirme sürecini yakından izler, çeşitli planlar hazırlar ve yürütür, gerekli ve yeterli kaynakları düzenler, maliyet, bütçe, kaynaklar, zaman, kalite ve müşteri memnuniyeti konularını ele almak için tüm ekip üyeleri arasında iletişimi sürdürür.

Bir proje yöneticisinin omuzladığı birkaç sorumluluğu görelim:

İnsanları yönetmek

• Proje lideri olarak hareket edin
• Paydaşlarla Lezyon
• İnsan kaynaklarını yönetmek
• Raporlama hiyerarşisi vb. Kurma

Proje Yönetimi

• Proje kapsamını tanımlama ve kurma
• Proje yönetimi faaliyetlerini yönetmek
• İlerlemeyi ve performansı izleme
• Her aşamada risk analizi
• Sorunlardan kaçınmak veya sorunlardan çıkmak için gerekli adımları atın
• Proje sözcüsü olarak hareket edin

Yazılım Yönetimi Faaliyetleri

Yazılım proje yönetimi, proje planlaması, yazılım ürününün kapsamına karar verme, çeşitli terimlerle maliyet tahmini, görevlerin ve olayların programlanması ve kaynak yönetimini içeren bir dizi faaliyetten oluşur. Proje yönetimi faaliyetleri şunları içerebilir:

• Project Planning
• Scope Management
• Project Estimation

Proje planlaması

Yazılım proje planlaması, yazılım üretimi fiilen başlamadan önce gerçekleştirilen görevdir. Yazılım üretimi için oradadır, ancak yazılım üretimi ile herhangi bir yön bağlantısı olan somut bir faaliyet içermez; daha ziyade, yazılım üretimini kolaylaştıran bir dizi çoklu süreçtir. Proje planlaması aşağıdakileri içerebilir:

Kapsam Yönetimi

Proje kapsamını tanımlar; bu, teslim edilebilir bir yazılım ürünü yapmak için yapılması gereken tüm faaliyetleri, süreci içerir. Kapsam yönetimi önemlidir çünkü projede ne yapılacağını ve neyin yapılmayacağını açıkça tanımlayarak projenin sınırlarını oluşturur. Bu, projenin sınırlı ve ölçülebilir görevler içermesini sağlar, bu da kolayca belgelenebilir ve dolayısıyla maliyet ve zaman aşımını önler.

Proje Kapsamı yönetimi sırasında aşağıdakileri yapmak gereklidir:

• Kapsamı tanımlayın
• Doğrulamasına ve kontrolüne karar verin
• Yönetim kolaylığı için projeyi çeşitli küçük parçalara bölün.
• Kapsamı doğrulayın
• Kapsamdaki değişiklikleri dahil ederek kapsamı kontrol edin

Proje Tahmini

Etkili bir yönetim için çeşitli önlemlerin doğru tahmin edilmesi şarttır. Doğru tahmin ile yöneticiler projeyi daha verimli ve etkili bir şekilde yönetebilir ve kontrol edebilir.

Proje tahmini aşağıdakileri içerebilir:

• Software size estimation

  Yazılım boyutu, KLOC (Kilo Satır Kod) veya yazılımdaki fonksiyon noktalarının sayısı hesaplanarak tahmin edilebilir. Kod satırları, kodlama uygulamalarına bağlıdır ve İşlev noktaları, kullanıcı veya yazılım gereksinimlerine göre değişir.

• Effort estimation

  Yöneticiler, çabaları, yazılımı üretmek için gereken personel ihtiyacı ve adam-saat açısından tahmin etmektedir. Efor tahmini için yazılım boyutu bilinmelidir. Bu, yöneticilerin deneyimlerinden, kuruluşun geçmiş verilerinden elde edilebilir veya yazılım boyutu, bazı standart formüller kullanılarak çabalara dönüştürülebilir.

• Time estimation

  Boyut ve çaba tahmin edildikten sonra, yazılımı üretmek için gereken süre tahmin edilebilir. Gerekli çabalar, yazılımın çeşitli bileşenlerinin gereksinim özelliklerine ve birbirine bağımlılığına göre alt kategorilere ayrılmıştır. Yazılım görevleri, Work Breakthrough Structure (WBS) tarafından daha küçük görevlere, aktivitelere veya olaylara bölünür. Görevler günlük bazda veya takvim ayları içinde planlanır.

  Tüm görevleri saat veya gün olarak tamamlamak için gereken toplam süre, projeyi tamamlamak için harcanan toplam süredir.

• Cost estimation

  Bu, en zoru olarak kabul edilebilir çünkü öncekilerden herhangi birinden daha fazla unsura bağlıdır. Proje maliyetini tahmin etmek için aşağıdakileri dikkate almak gerekir -

• Yazılımın boyutu
• Yazılım kalitesi
• Hardware
• Ek yazılım veya araçlar, lisanslar vb.
• Göreve özgü becerilere sahip yetenekli personel
• Seyahat dahil
• Communication
• Eğitim ve destek

Proje Tahmin Teknikleri

Boyut, çaba, zaman ve maliyet gibi proje tahminini içeren çeşitli parametreleri tartıştık.

Proje yöneticisi, genel olarak tanınan iki tekniği kullanarak listelenen faktörleri tahmin edebilir -

Ayrıştırma Tekniği

Bu teknik, yazılımı çeşitli kompozisyonların bir ürünü olarak varsayar.

İki ana model var -

• Line of Code Yazılım ürünündeki kod satırı sayısı adına tahmin yapılır.
• Function Points Yazılım ürünündeki fonksiyon noktalarının sayısı adına tahmin yapılır.

Ampirik Tahmin Tekniği

Bu teknik, tahmin yapmak için deneysel olarak türetilmiş formüller kullanır. Bu formüller LOC veya FP'lere dayanır.

• Putnam Model

  Bu model, Norden'in frekans dağılımına (Rayleigh eğrisi) dayanan Lawrence H. Putnam tarafından yapılmıştır. Putnam modeli, yazılım boyutuyla birlikte gereken zamanı ve çabayı eşler.

• COCOMO

  COCOMO, Barry W. Boehm tarafından geliştirilen COnstructive COst MOdel'in kısaltmasıdır. Yazılım ürününü üç yazılım kategorisine ayırır: organik, yarı bağımsız ve gömülü.

Proje Çizelgeleme

Bir projede Proje Çizelgeleme, belirli bir sırayla ve her bir faaliyete ayrılan zaman aralığı içinde yapılacak tüm faaliyetlerin yol haritasını ifade eder. Proje yöneticileri, çeşitli görevleri ve proje kilometre taşlarını tanımlama ve bunları çeşitli faktörleri göz önünde bulundurarak düzenleme eğilimindedir. Belirli bir şekilde (görevlerin birbirine bağlı olması nedeniyle) ve kesinlikle ayrılan süre içinde tamamlanması gereken, çizelgedeki kritik yolda bulunan görevleri ararlar. Kritik yolun dışında kalan görevlerin düzenlenmesi, projenin tüm programını etkileme olasılığı daha düşüktür.

Bir projeyi planlamak için şunlara ihtiyaç vardır:

• Proje görevlerini daha küçük, yönetilebilir biçime ayırın
• Çeşitli görevleri bulun ve bunları ilişkilendirin
• Her görev için gerekli zaman dilimini tahmin edin
• Zamanı çalışma birimlerine ayırın
• Her görev için yeterli sayıda çalışma birimi atayın
• Proje için baştan sona kadar gereken toplam süreyi hesaplayın

Kaynak yönetimi

Bir yazılım ürünü geliştirmek için kullanılan tüm unsurlar, o proje için kaynak olarak kabul edilebilir. Bu, insan kaynaklarını, üretken araçları ve yazılım kitaplıklarını içerebilir.

Kaynaklar sınırlı miktarda mevcuttur ve kuruluşta bir varlık havuzu olarak kalır. Kaynak yetersizliği projenin gelişimini engeller ve programın gerisinde kalabilir. Ekstra kaynak ayırmak, sonunda geliştirme maliyetini artırır. Bu nedenle proje için yeterli kaynakların tahmin edilmesi ve tahsis edilmesi gerekmektedir.

Kaynak yönetimi şunları içerir -

• Bir proje ekibi oluşturarak ve her ekip üyesine sorumluluklar atayarak uygun organizasyon projesini tanımlamak
• Belirli bir aşamada ihtiyaç duyulan kaynakları ve bunların kullanılabilirliğini belirleme
• Gerektiğinde kaynak talebi oluşturarak ve daha fazla ihtiyaç duyulmadığında ayırmayı kaldırarak Kaynakları Yönetin.

Proje Risk Yönetimi

Risk yönetimi, projedeki öngörülebilir ve öngörülemeyen risklerin belirlenmesi, analizi ve provizyonu ile ilgili tüm faaliyetleri içerir. Risk aşağıdakileri içerebilir:

• Projeden ayrılan deneyimli personel ve yeni personel geliyor.
• Organizasyonel yönetimde değişiklik.
• Gereksinim değişikliği veya yanlış yorumlama gereksinimi.
• Gerekli zaman ve kaynakların eksik tahmini.
• Teknolojik değişiklikler, çevresel değişiklikler, iş rekabeti.

Risk Yönetimi Süreci

Risk yönetimi sürecine dahil olan aşağıdaki faaliyetler vardır:

• Identification - Projede oluşabilecek tüm olası riskleri not edin.
• Categorize - Bilinen riskleri proje üzerindeki olası etkilerine göre yüksek, orta ve düşük risk yoğunluğu olarak sınıflandırın.
• Manage - Çeşitli aşamalarda risklerin oluşma olasılığını analiz edin. Risklerden kaçınmak veya risklerle yüzleşmek için plan yapın. Yan etkilerini en aza indirmeye çalışın.
• Monitor - Potansiyel riskleri ve bunların erken semptomlarını yakından izleyin. Ayrıca bunları azaltmak veya önlemek için atılan adımların etkilerini de izleyin.

Proje Yürütme ve İzleme

Bu aşamada proje planlarında açıklanan görevler programlarına göre yürütülür.

Her şeyin plana göre gidip gitmediğini kontrol etmek için yürütmenin izlenmesi gerekir. İzleme, risk olasılığını kontrol etmek için gözlem yapmak ve riski ele almak veya çeşitli görevlerin durumunu bildirmek için önlemler almaktır.

Bu önlemler şunları içerir:

• Activity Monitoring - Bazı görevler dahilinde planlanan tüm aktiviteler günlük bazda izlenebilir. Bir görevdeki tüm aktiviteler tamamlandığında tamamlanmış sayılır.
• Status Reports - Raporlar, genellikle bir hafta olmak üzere belirli bir zaman çerçevesi içinde tamamlanan etkinliklerin ve görevlerin durumunu içerir. Durum, tamamlandı, beklemede veya devam eden çalışma vb. Olarak işaretlenebilir.
• Milestones Checklist - Her proje, SDLC aşamalarına bağlı olarak ana görevlerin (kilometre taşları) gerçekleştirildiği birden çok aşamaya bölünmüştür. Bu kilometre taşı kontrol listesi birkaç haftada bir hazırlanır ve kilometre taşlarının durumunu bildirir.

Proje İletişim Yönetimi

Etkili iletişim, bir projenin başarısında hayati bir rol oynar. Müşteri ile organizasyon, ekip üyeleri ve donanım tedarikçileri gibi projedeki diğer paydaşlar arasındaki boşlukları kapatır.

İletişim sözlü veya yazılı olabilir. İletişim yönetimi süreci aşağıdaki adımlardan oluşabilir:

• Planning - Bu adım, projedeki tüm paydaşların tanımlanmasını ve bunlar arasındaki iletişim şeklini içerir. Ayrıca, herhangi bir ek iletişim aracının gerekli olup olmadığını da değerlendirir.
• Sharing - Planlamanın çeşitli yönlerini belirledikten sonra yönetici, doğru bilgiyi doğru zamanda doğru kişiyle paylaşmaya odaklanır. Bu, projeye dahil olan herkesin proje ilerlemesi ve durumu ile güncel kalmasını sağlar.
• Feedback - Proje yöneticileri, çeşitli ölçümler ve geri bildirim mekanizması kullanır ve durum ve performans raporları oluşturur. Bu mekanizma, çeşitli paydaşlardan gelen girdilerin proje yöneticisine geri bildirimleri olarak gelmesini sağlar.
• Closure - Her büyük olayın sonunda, SDLC'nin bir aşamasının sonunda veya projenin kendisinin sonunda, e-posta göndererek, bir belgenin basılı kopyasını dağıtarak veya diğer etkili iletişim araçlarıyla her paydaşın güncellenmesi için idari kapatma resmi olarak duyurulur.

Kapanıştan sonra ekip bir sonraki aşamaya veya projeye geçer.

Konfigürasyon yönetimi

Konfigürasyon yönetimi, yazılımdaki değişiklikleri ürünün gereksinimleri, tasarımı, işlevleri ve gelişimi açısından izleme ve kontrol etme sürecidir.

IEEE, bunu “sistemdeki öğeleri tanımlama ve tanımlama, yaşam döngüleri boyunca bu öğelerin değişimini kontrol etme, öğelerin durumunu kaydetme ve raporlama ve öğelerin eksiksizliğini ve doğruluğunu doğrulama süreci” olarak tanımlar.

Genel olarak, SRS bir kez sonuçlandırıldığında, kullanıcıdan değişiklik yapma gereksinimi olasılığı daha azdır. Meydana gelirse, maliyet ve zaman aşımı olasılığı olduğundan değişiklikler yalnızca üst yönetimin önceden onayı ile ele alınır.

Temel

Temel olarak belirlenmişse, SDLC fazının üzerinde olduğu varsayılır, yani temel hat, bir fazın tamlığını tanımlayan bir ölçümdür. Bir aşama, kendisiyle ilgili tüm faaliyetler tamamlandığında ve iyi bir şekilde belgelendiğinde temel alınır. Son aşama olmasaydı, çıktısı bir sonraki acil aşamada kullanılacaktır.

Konfigürasyon yönetimi, bir aşama temel alındıktan sonra herhangi bir değişikliğin (süreç, gereksinim, teknolojik, stratejik vb.) Ortaya çıkmasına özen gösteren bir organizasyon yönetimi disiplinidir. CM, yazılımda yapılan değişiklikleri kontrol eder.

Kontrolü değiştir

Değişiklik kontrolü, yazılım sisteminde yapılan tüm değişikliklerin tutarlı olmasını ve kurumsal kural ve düzenlemelere göre yapılmasını sağlayan konfigürasyon yönetiminin bir işlevidir.

Ürün konfigürasyonundaki bir değişiklik aşağıdaki adımlardan geçer -

• Identification- Dahili veya harici kaynaktan bir değişiklik talebi gelir. Değişiklik talebi resmi olarak tanımlandığında, uygun şekilde belgelenir.

• Validation - Değişiklik talebinin geçerliliği kontrol edilir ve işlem prosedürü onaylanır.

• Analysis- Değişiklik talebinin etkisi, program, maliyet ve gerekli çabalar açısından analiz edilir. İleriye dönük değişikliğin sistem üzerindeki genel etkisi analiz edilir.

• Control- Olası değişiklik, sistemdeki çok fazla kuruluşu etkiliyorsa veya kaçınılmazsa, değişiklik sisteme dahil edilmeden önce yüksek makamların onayının alınması zorunludur. Değişikliğin dahil edilmeye değer olup olmadığına karar verilir. Aksi takdirde değişiklik talebi resmi olarak reddedilir.

• Execution - Önceki aşama, değişiklik talebini yerine getirmeyi belirlerse, bu aşama, değişikliği gerçekleştirmek için uygun işlemleri yapar, gerekirse kapsamlı bir revizyon yapar.

• Close request- Değişiklik, doğru uygulama ve sistemin geri kalanıyla birleşme için doğrulanır. Yazılıma yeni dahil edilen bu değişiklik uygun şekilde belgelenir ve talep resmi olarak kapatılır.

Proje Yönetim Araçları

Proje belirlenen metodolojilere göre geliştirilse bile, risk ve belirsizlik projenin büyüklüğüne göre çok kat artmaktadır.

Etkili proje yönetimine yardımcı olan araçlar mevcuttur. Birkaç tanesi açıklanmıştır -

Gantt şeması

Gantt çizelgeleri Henry Gantt (1917) tarafından tasarlanmıştır. Zaman dönemlerine göre proje programını temsil eder. Proje etkinlikleri için planlanan etkinlikleri ve zamanı temsil eden çubukların bulunduğu yatay bir çubuk grafiktir.

PERT Şeması

PERT (Program Değerlendirme ve Gözden Geçirme Tekniği) şeması, projeyi ağ diyagramı olarak gösteren bir araçtır. Projenin ana olaylarını hem paralel hem de ardışık olarak grafiksel olarak temsil edebilir. Birbiri ardına meydana gelen olaylar, daha sonraki olayın bir öncekine bağımlılığını gösterir.

Olaylar numaralandırılmış düğümler olarak gösterilir. Projedeki görevlerin sırasını gösteren etiketli oklarla birbirine bağlanırlar.

Kaynak Histogramı

Bu, bir proje etkinliği (veya aşaması) için zaman içinde gerekli olan kaynakların (genellikle vasıflı personel) sayısını temsil eden çubuk veya grafiği içeren grafiksel bir araçtır. Kaynak Histogramı, personel planlaması ve koordinasyonu için etkili bir araçtır.

Kritik Yol Analizi

Bu araçlar, projedeki birbirine bağlı görevleri tanımak için kullanışlıdır. Ayrıca, projeyi başarıyla tamamlamak için en kısa yolu veya kritik yolu bulmaya yardımcı olur. PERT diyagramı gibi, her olaya belirli bir zaman çerçevesi tahsis edilir. Bu araç, bir olayın yalnızca bir önceki tamamlandığında bir sonrakine ilerleyebileceğini varsayarak olayın bağımlılığını gösterir.

Olaylar, mümkün olan en erken başlama saatlerine göre düzenlenir. Başlangıç ​​ve bitiş düğümü arasındaki yol, daha fazla azaltılamayan ve tüm olayların aynı sırada yürütülmesi gereken kritik yoldur.

Yazılım gereksinimleri, hedef sistemin özelliklerinin ve işlevlerinin açıklamalarıdır. Gereksinimler, kullanıcıların yazılım ürününden beklentilerini iletir. Gereksinimler açık veya gizli, bilinen veya bilinmeyen, müşterinin bakış açısından beklenen veya beklenmeyen olabilir.

Gereksinim Mühendisliği

Yazılım gereksinimlerini müşteriden toplama, analiz etme ve belgeleme süreci, gereksinim mühendisliği olarak bilinir.

Gereksinim mühendisliğinin amacı, sofistike ve açıklayıcı 'Sistem Gereksinimleri Belirtimi' belgesini geliştirmek ve sürdürmektir.

Gereksinim Mühendislik Süreci

Bu, aşağıdakileri içeren dört adımlı bir süreçtir:

• Fizibilite çalışması
• Şartlı toplantı
• Yazılım Gereksinimi Özellikleri
• Yazılım Gereksinim Doğrulaması

Süreci kısaca görelim -

Fizibilite çalışması

Müşteri, istenen ürünü geliştirmek için kuruluşa yaklaştığında, yazılımın tüm işlevlerini yerine getirmesi gerektiği ve yazılımdan hangi özelliklerin beklendiği konusunda kabaca bir fikir ortaya çıkar.

Analistler, bu bilgilere başvurarak, istenen sistemin ve onun işlevselliğinin geliştirilmesinin uygun olup olmadığı hakkında ayrıntılı bir çalışma yapar.

Bu fizibilite çalışması, organizasyonun amacına odaklanmıştır. Bu çalışma, yazılım ürününün uygulama, projenin organizasyona katkısı, maliyet kısıtlamaları ve organizasyonun değer ve hedeflerine göre pratik olarak gerçekleştirilip gerçekleştirilemeyeceğini analiz etmektedir. Kullanılabilirlik, sürdürülebilirlik, üretkenlik ve entegrasyon yeteneği gibi proje ve ürünün teknik yönlerini araştırır.

Bu aşamanın çıktısı, projenin üstlenilip üstlenilmemesi konusunda yönetim için yeterli yorum ve tavsiyeleri içermesi gereken bir fizibilite çalışması raporu olmalıdır.

Şartlı toplantı

Fizibilite raporu projeyi üstlenmeye yönelik olumlu ise, sonraki aşama kullanıcıdan gereksinimlerin alınmasıyla başlar. Analistler ve mühendisler, yazılımın ne sağlaması gerektiği ve yazılımın hangi özellikleri içermesini istedikleri konusundaki fikirlerini öğrenmek için müşteri ve son kullanıcılarla iletişim kurar.

Yazılım Gereksinimi Özellikleri

SRS, ihtiyaçlar çeşitli paydaşlardan toplandıktan sonra sistem analisti tarafından oluşturulan bir belgedir.

SRS, amaçlanan yazılımın donanım, harici arayüzler, çalışma hızı, sistemin yanıt süresi, yazılımın çeşitli platformlarda taşınabilirliği, bakım kolaylığı, çökme sonrası kurtarma hızı, Güvenlik, Kalite, Sınırlamalar vb. İle nasıl etkileşime gireceğini tanımlar.

Müşteriden alınan talepler doğal dilde yazılmıştır. Yazılım geliştirme ekibi tarafından anlaşılabilmeleri ve faydalı olabilmeleri için gereksinimleri teknik dilde belgelemek sistem analistinin sorumluluğundadır.

SRS aşağıdaki özelliklerle gelmelidir:

• Kullanıcı Gereksinimleri doğal dilde ifade edilir.
• Teknik gereksinimler, organizasyon içinde kullanılan yapılandırılmış bir dille ifade edilir.
• Tasarım açıklaması Pseudo kod ile yazılmalıdır.
• Form Formatı ve GUI ekran baskıları.
• DFD'ler vb. İçin koşullu ve matematiksel gösterimler

Yazılım Gereksinim Doğrulaması

Gereksinim özellikleri geliştirildikten sonra, bu belgede belirtilen gereksinimler doğrulanır. Kullanıcı yasa dışı, pratik olmayan çözüm isteyebilir veya uzmanlar gereksinimleri yanlış yorumlayabilir. Bu, başlangıçta engellenmezse maliyette büyük artışla sonuçlanır. Gereksinimler aşağıdaki koşullara göre kontrol edilebilir -

• Pratik olarak uygulanabilirse
• Geçerliyse ve yazılımın işlevselliği ve etki alanına göre
• Herhangi bir belirsizlik varsa
• Eğer tamamlanmışlarsa
• Gösterilebilirlerse

Gereksinim Ortaya Çıkarma Süreci

Gereksinim belirleme süreci aşağıdaki diyagram kullanılarak gösterilebilir:

• Requirements gathering - Geliştiriciler, müşteri ve son kullanıcı ile tartışır ve yazılımdan beklentilerini bilir.
• Organizing Requirements - Geliştiriciler, gereksinimleri önem, aciliyet ve uygunluk sırasına göre önceliklendirir ve düzenler.

• Negotiation & discussion - Gereksinimler belirsizse veya çeşitli paydaşların gereksinimlerinde bazı çatışmalar varsa, öyleyse, paydaşlarla müzakere edilir ve tartışılır. Gereksinimler daha sonra önceliklendirilebilir ve makul ölçüde tehlikeye atılabilir.

  Gereksinimler çeşitli paydaşlardan gelir. Belirsizliği ve çatışmaları ortadan kaldırmak için açıklık ve doğruluk için tartışılırlar. Gerçekçi olmayan gereksinimler makul bir şekilde tehlikeye atılır.

• Documentation - Tüm resmi ve gayri resmi, işlevsel ve işlevsel olmayan gereksinimler belgelenir ve bir sonraki aşama işleme için hazır hale getirilir.

Gereksinim Ortaya Çıkarma Teknikleri

Gereksinimler Ortaya Çıkarma, müşteri, son kullanıcılar, sistem kullanıcıları ve yazılım sistemi geliştirmede payı olan diğer kişilerle iletişim kurarak amaçlanan bir yazılım sistemi için gereksinimleri bulma sürecidir.

Gereksinimleri keşfetmenin çeşitli yolları vardır

Mülakatlar

Mülakatlar, gereksinimleri toplamak için güçlü bir araçtır. Kuruluş, aşağıdakiler gibi birkaç tür görüşme yapabilir:

• Toplanacak her bir bilginin önceden kararlaştırıldığı yapılandırılmış (kapalı) görüşmeler, düzeni ve tartışma konusunu sıkı bir şekilde takip ederler.
• Toplanacak bilgilerin önceden kararlaştırılmadığı, daha esnek ve daha az önyargılı olduğu yapılandırılmamış (açık) görüşmeler.
• Sözlü görüşmeler
• Yazılı görüşmeler
• Masanın karşısında iki kişi arasında yapılan bire bir görüşmeler.
• Katılımcı grupları arasında yapılan grup görüşmeleri. İşin içinde çok sayıda insan olduğu için eksik gereksinimleri ortaya çıkarmaya yardımcı olurlar.

Anketler

Kuruluş, gelecek sistemden beklentilerini ve gereksinimlerini sorgulayarak çeşitli paydaşlar arasında anketler yapabilir.

Anketler

Önceden tanımlanmış nesnel sorular ve ilgili seçenekler içeren bir belge, toplanıp derlenen yanıtlamaları için tüm paydaşlara verilir.

Bu tekniğin bir dezavantajı, ankette bazı konular için bir seçenek belirtilmezse, sorunun gözetimsiz bırakılabilmesidir.

Görev Analizi

Mühendis ve geliştiricilerden oluşan ekip, yeni sistemin gerekli olduğu operasyonu analiz edebilir. Müşterinin belirli bir işlemi gerçekleştirmek için halihazırda bir yazılımı varsa, incelenir ve önerilen sistemin gereksinimleri toplanır.

Alan Analizi

Her yazılım bazı alan kategorilerine girer. Alandaki uzman kişiler, genel ve özel gereksinimleri analiz etmek için çok yardımcı olabilir.

Beyin fırtınası

Çeşitli paydaşlar arasında gayri resmi bir tartışma yapılır ve tüm girdileri daha ileri gereksinim analizi için kaydedilir.

Prototipleme

Prototip oluşturma, kullanıcının amaçlanan yazılım ürününün özelliklerini yorumlaması için ayrıntı işlevselliği eklemeden kullanıcı arayüzü oluşturmaktır. Gereksinimler hakkında daha iyi fikir vermeye yardımcı olur. Müşterinin sonunda geliştiricinin referansı için kurulu bir yazılım yoksa ve müşteri kendi gereksinimlerinin farkında değilse, geliştirici başlangıçta belirtilen gereksinimleri temel alan bir prototip oluşturur. Prototip müşteriye gösterilir ve geri bildirim not edilir. Müşteri geri bildirimi, gereksinim toplama için bir girdi görevi görür.

Gözlem

Uzmanlardan oluşan ekip, müşterinin organizasyonunu veya işyerini ziyaret eder. Mevcut kurulu sistemlerin fiili çalışmasını gözlemlerler. İş akışını müşterinin sonunda ve yürütme sorunlarının nasıl ele alındığını gözlemlerler. Ekibin kendisi, yazılımdan beklenen gereksinimleri oluşturmaya yardımcı olan bazı sonuçlar çıkarır.

Yazılım Gereksinimlerinin Özellikleri

Yazılım gereksinimlerinin toplanması, tüm yazılım geliştirme projesinin temelidir. Bu nedenle açık, doğru ve iyi tanımlanmış olmalıdırlar.

Tam bir Yazılım Gereksinimi Spesifikasyonu şöyle olmalıdır:

• Clear
• Correct
• Consistent
• Coherent
• Comprehensible
• Modifiable
• Verifiable
• Prioritized
• Unambiguous
• Traceable
• Güvenilir kaynak

yazılım gereksinimleri

Gereksinim belirleme aşamasında ne tür gereksinimlerin ortaya çıkabileceğini ve yazılım sisteminden ne tür gereksinimler beklendiğini anlamaya çalışmalıyız.

Genel olarak yazılım gereksinimleri iki kategoriye ayrılmalıdır:

İşlevsel gereksinimler

Yazılımın işlevsel yönüyle ilgili gereksinimler bu kategoriye girer.

Yazılım sistemi içindeki ve yazılım sisteminden işlevleri ve işlevselliği tanımlarlar.

Örnekler -

• Kullanıcıya çeşitli faturalardan arama yapma imkanı verilen arama seçeneği.
• Kullanıcı herhangi bir raporu yönetime postalayabilmelidir.
• Kullanıcılar gruplara ayrılabilir ve gruplara ayrı haklar verilebilir.
• İş kurallarına ve idari işlevlere uymalıdır.
• Yazılım, aşağı doğru uyumluluğu sağlam tutarak geliştirilmiştir.

İşlevsel Olmayan Gereksinimler

Yazılımın işlevsel yönüyle ilgili olmayan gereksinimler bu kategoriye girer. Yazılımın, kullanıcıların varsaydığı, örtük veya beklenen özellikleridir.

İşlevsel olmayan gereksinimler şunları içerir:

• Security
• Logging
• Storage
• Configuration
• Performance
• Cost
• Interoperability
• Flexibility
• Felaket kurtarma
• Accessibility

Gereksinimler mantıksal olarak şu şekilde kategorize edilir:

• Must Have : Yazılımlar olmadan çalışır durumda olduğu söylenemez.
• Should have : Yazılımın işlevselliğini geliştirmek.
• Could have : Yazılım, bu gereksinimlerle hala düzgün bir şekilde çalışabilir.
• Wish list : Bu gereksinimler, herhangi bir yazılım hedefiyle eşleşmez.

Yazılım geliştirirken 'Olmalı' uygulanmalıdır, 'Olmalı' paydaşlarla tartışma ve olumsuzluk konusudur, oysa 'olabilir' ve 'dilek listesi' yazılım güncellemeleri için tutulabilir.

Kullanıcı Arayüzü gereksinimleri

UI, herhangi bir yazılımın veya donanımın veya hibrit sistemin önemli bir parçasıdır. Bir yazılım yaygın olarak kabul edilir:

• kullanımı kolay
• hızlı yanıt
• operasyonel hataların etkin bir şekilde ele alınması
• basit ama tutarlı bir kullanıcı arayüzü sağlamak

Kullanıcı kabulü, büyük ölçüde kullanıcının yazılımı nasıl kullanabileceğine bağlıdır. Kullanıcıların sistemi algılamasının tek yolu UI'dir. İyi performans gösteren bir yazılım sistemi ayrıca çekici, net, tutarlı ve duyarlı bir kullanıcı arayüzü ile donatılmalıdır. Aksi takdirde yazılım sisteminin işlevleri rahat bir şekilde kullanılamaz. Bir sistemin verimli bir şekilde kullanılması için araçlar sağlıyorsa iyi olduğu söylenir. Kullanıcı arayüzü gereksinimleri aşağıda kısaca belirtilmiştir -

• İçerik sunumu
• Kolay Gezinme
• Basit arayüz
• Responsive
• Tutarlı UI öğeleri
• Geribildirim mekanizması
• Varsayılan ayarları
• Amaca yönelik düzen
• Renk ve dokunun stratejik kullanımı.
• Yardım bilgileri sağlayın
• Kullanıcı merkezli yaklaşım
• Grup bazlı görünüm ayarları.

Yazılım Sistem Analisti

Bir BT organizasyonundaki sistem analisti, önerilen sistemin gerekliliğini analiz eden ve gereksinimlerin doğru ve doğru bir şekilde tasarlanmasını ve belgelendirilmesini sağlayan kişidir. Bir analistin rolü, SDLC'nin Yazılım Analizi Aşamasında başlar. Geliştirilen yazılımın müşterinin gereksinimlerini karşıladığından emin olmak analistin sorumluluğundadır.

Sistem Analistleri aşağıdaki sorumluluklara sahiptir:

• Amaçlanan yazılımın gereksinimlerini analiz etmek ve anlamak
• Projenin organizasyon hedeflerine nasıl katkıda bulunacağını anlamak
• Gereksinim kaynaklarını belirleyin
• Gereksinimin doğrulanması
• İhtiyaç yönetimi planı geliştirin ve uygulayın
• İş, teknik, süreç ve ürün gereksinimlerinin dokümantasyonu
• Gereksinimlere öncelik vermek ve belirsizliği ortadan kaldırmak için müşterilerle koordinasyon
• Müşteri ve diğer paydaşlar ile kabul kriterlerinin tamamlanması

Yazılım Metrikleri ve Önlemleri

Yazılım Ölçüleri, yazılımın çeşitli niteliklerini ve yönlerini ölçmek ve simgelemek için bir süreç olarak anlaşılabilir.

Yazılım Ölçütleri, yazılım sürecinin ve yazılım ürününün çeşitli yönleri için önlemler sağlar.

Yazılım önlemleri, yazılım mühendisliğinin temel gereksinimidir. Yalnızca yazılım geliştirme sürecini kontrol etmeye yardımcı olmakla kalmaz, aynı zamanda nihai ürünün kalitesini mükemmel tutmaya da yardımcı olurlar.

Bir (Yazılım Mühendisi) olan Tom DeMarco'ya göre, "Ölçemediğiniz şeyi kontrol edemezsiniz." Onun sözüyle, yazılım önlemlerinin ne kadar önemli olduğu çok açık.

Bazı yazılım ölçütlerini görelim:

• Size Metrics - Çoğunlukla teslim edilen binlerce kaynak kodu satırında hesaplanan LOC (Kod Satırları) KLOC olarak adlandırılır.

  Function Point Count, yazılım tarafından sağlanan işlevselliğin ölçüsüdür. İşlev Nokta sayısı, yazılımın işlevsel yönünün boyutunu tanımlar.

• Complexity Metrics - McCabe'nin Siklomatik karmaşıklığı, programın veya modüllerinin karmaşıklığı olarak algılanan bir programdaki bağımsız yolların sayısının üst sınırını ölçer. Kontrol akış grafiği kullanılarak grafik teorisi kavramları ile temsil edilir.

• Quality Metrics - Kusurlar, türleri ve nedenleri, sonuçları, ciddiyet yoğunluğu ve sonuçları ürünün kalitesini tanımlar.

  Ürün müşteri tarafında kurulduktan veya teslim edildikten sonra geliştirme sürecinde bulunan kusurların sayısı ve müşteri tarafından bildirilen kusurların sayısı, ürünün kalitesini tanımlar.

• Process Metrics - SDLC'nin çeşitli aşamalarında, kullanılan yöntemler ve araçlar, şirket standartları ve geliştirme performansı, yazılım süreci metrikleridir.
• Resource Metrics - Kullanılan çaba, zaman ve çeşitli kaynaklar, kaynak ölçümü için ölçütleri temsil eder.

Yazılım tasarımı, kullanıcı gereksinimlerini uygun bir biçime dönüştürmek için bir süreçtir ve programcıya yazılım kodlaması ve uygulamasında yardımcı olur.

Kullanıcı gereksinimlerini değerlendirmek için bir SRS (Yazılım Gereksinim Belirtimi) belgesi oluşturulurken, kodlama ve uygulama için yazılım açısından daha özel ve ayrıntılı gereksinimlere ihtiyaç vardır. Bu işlemin çıktısı, programlama dillerinde doğrudan uygulanmasında kullanılabilir.

Yazılım tasarımı, konsantrasyonu problem alanından çözüm alanına taşıyan SDLC'nin (Yazılım Tasarım Yaşam Döngüsü) ilk adımıdır. SRS'de belirtilen gerekliliklerin nasıl yerine getirileceğini belirlemeye çalışır.

Yazılım Tasarım Seviyeleri

Yazılım tasarımı üç düzeyde sonuç verir:

• Architectural Design - Mimari tasarım, sistemin en yüksek soyut versiyonudur. Yazılımı, birbiriyle etkileşim halindeki birçok bileşenin bulunduğu bir sistem olarak tanımlar. Bu seviyede, tasarımcılar önerilen çözüm alanı fikrine sahip olurlar.
• High-level Design- Üst düzey tasarım, mimari tasarımın 'tek varlık-çok bileşenli' konseptini, alt sistemlerin ve modüllerin daha az soyutlanmış görünümüne böler ve bunların birbirleriyle etkileşimlerini tasvir eder. Üst düzey tasarım, sistemin tüm bileşenleri ile birlikte modüller biçiminde nasıl uygulanabileceğine odaklanır. Her bir alt sistemin modüler yapısını ve birbirleriyle ilişkilerini ve etkileşimini tanır.
• Detailed Design- Detaylı tasarım, önceki iki tasarımda bir sistem ve alt sistemleri olarak görülen şeyin uygulama kısmı ile ilgilidir. Modüllere ve uygulamalarına yönelik daha ayrıntılıdır. Her modülün mantıksal yapısını ve diğer modüllerle iletişim kurmak için arayüzlerini tanımlar.

Modülerleştirme

Modülerleştirme, bir yazılım sistemini, görevleri bağımsız olarak yerine getirmesi beklenen çok sayıda ayrı ve bağımsız modüle bölme tekniğidir. Bu modüller, tüm yazılım için temel yapılar olarak çalışabilir. Tasarımcılar, ayrı ayrı ve bağımsız olarak yürütülebilecekleri ve / veya derlenebilecekleri modüller tasarlama eğilimindedir.

Modüler tasarım, istemeden 'böl ve yönet' problem çözme stratejisi kurallarını takip eder, çünkü bir yazılımın modüler tasarımına eklenen birçok başka fayda vardır.

Modülerleştirmenin avantajı:

• Daha küçük bileşenlerin bakımı daha kolaydır
• Program fonksiyonel yönlere göre bölünebilir
• Programa istenilen düzeyde soyutlama getirilebilir
• Yüksek kohezyonlu bileşenler tekrar tekrar kullanılabilir
• Eşzamanlı yürütme mümkün hale getirilebilir
• Güvenlik açısından istenen

Eşzamanlılık

Geçmişte, tüm yazılımların sıralı olarak çalıştırılması amaçlanmıştır. Sıralı yürütme ile, kodlanmış talimatın, herhangi bir zamanda, programın yalnızca bir bölümünün etkinleştirildiğini ima ederek, birbiri ardına çalıştırılacağını kastediyoruz. Diyelim ki, bir yazılımın birden fazla modülü vardır, o zaman tüm modüllerden yalnızca biri yürütme sırasında herhangi bir anda aktif olarak bulunabilir.

Yazılım tasarımında eşzamanlılık, yazılımı modüller gibi birden çok bağımsız yürütme birimine bölerek ve bunları paralel olarak çalıştırarak uygulanır. Başka bir deyişle, eşzamanlılık, yazılıma birden fazla kod parçasını birbirine paralel olarak yürütme yeteneği sağlar.

Programcıların ve tasarımcıların paralel olarak çalıştırılabilen modülleri tanıması gerekir.

Misal

Kelime işlemcideki yazım denetimi özelliği, kelime işlemcinin yanında çalışan bir yazılım modülüdür.

Kaplin ve Uyum

Bir yazılım programı modülerleştirildiğinde, görevleri bazı özelliklere göre birkaç modüle bölünür. Bildiğimiz gibi modüller, bazı görevleri yerine getirmek için bir araya getirilen talimatlar dizisidir. Yine de, tek bir varlık olarak kabul edilirler ancak birlikte çalışmak için birbirlerine başvurabilirler. Modül tasarımının kalitesinin ve aralarındaki etkileşiminin ölçülebileceği ölçüler vardır. Bu önlemlere birleştirme ve uyum denir.

Uyum

Uyum, bir modülün öğeleri içindeki iç güvenilirlik derecesini tanımlayan bir ölçüdür. Uyum ne kadar büyükse program tasarımı o kadar iyidir.

Yedi tür uyum vardır, yani -

• Co-incidental cohesion -Programın modülerleştirme adına daha küçük modüllere bölünmesinin bir sonucu olabilecek plansız ve rastgele uyumdur. Plansız olduğu için programcıların kafasını karıştırabilir ve genellikle kabul edilmez.
• Logical cohesion - Mantıksal olarak kategorize edilmiş öğeler bir modülde bir araya getirildiğinde, buna mantıksal uyum denir.
• emporal Cohesion - Modül öğeleri zaman içinde benzer bir noktada işlenecek şekilde düzenlendiğinde, buna zamansal uyum denir.
• Procedural cohesion - Bir görevi gerçekleştirmek için sırayla yürütülen modül öğeleri bir arada gruplandırıldığında, buna prosedürsel uyum denir.
• Communicational cohesion - Sıralı olarak yürütülen ve aynı veriler (bilgiler) üzerinde çalışan modül öğeleri birlikte gruplandırıldığında, buna iletişimsel uyum denir.
• Sequential cohesion - Modül öğeleri gruplandığında, bir öğenin çıktısı diğerine girdi olarak hizmet ettiğinden vb. Buna sıralı uyum denir.
• Functional cohesion - En yüksek uyum derecesi olarak kabul edilir ve çok beklenen bir durumdur. İşlevsel uyumdaki modül unsurları, tek bir iyi tanımlanmış işleve katkıda bulundukları için gruplandırılmıştır. Ayrıca yeniden kullanılabilir.

Kaplin

Birleştirme, bir programın modülleri arasındaki birbirine bağımlılık düzeyini tanımlayan bir ölçüdür. Modüllerin hangi düzeyde müdahale ettiğini ve birbirleriyle etkileşime girdiğini söyler. Kaplin ne kadar düşükse program o kadar iyi olur.

Beş bağlantı seviyesi vardır, yani -

• Content coupling - Bir modül, başka bir modülün içeriğine doğrudan erişebildiği veya bunları değiştirebildiği veya bunlara atıfta bulunduğu zaman, buna içerik seviyesi eşleştirme denir.
• Common coupling- Birden fazla modülün bazı global verilere okuma ve yazma erişimi olduğunda, buna ortak veya global kuplaj denir.
• Control coupling- İki modül, biri diğer modülün işlevine karar verirse veya yürütme akışını değiştirirse, kontrol-bağlantılı olarak adlandırılır.
• Stamp coupling- Birden fazla modül ortak veri yapısını paylaştığında ve farklı kısımlarında çalıştığında, buna damga birleştirme denir.
• Data coupling- Veri birleştirme, iki modülün veri iletimi yoluyla (parametre olarak) birbiriyle etkileşime girmesidir. Bir modül veri yapısını parametre olarak geçirirse, alıcı modül tüm bileşenlerini kullanmalıdır.

İdeal olarak, hiçbir bağlantı en iyisi olarak kabul edilmez.

Tasarım Doğrulaması

Yazılım tasarım sürecinin çıktısı tasarım dokümantasyonu, sözde kodlar, ayrıntılı mantık diyagramları, süreç diyagramları ve tüm işlevsel veya işlevsel olmayan gereksinimlerin ayrıntılı açıklamasıdır.

Yazılımın uygulanması olan bir sonraki aşama, yukarıda bahsedilen tüm çıktılara bağlıdır.

Daha sonra bir sonraki aşamaya geçmeden önce çıktının doğrulanması gerekli hale gelir. Herhangi bir hata ne kadar erken tespit edilirse, o kadar iyidir veya ürünün test edilmesine kadar tespit edilemeyebilir. Tasarım aşamasının çıktıları resmi gösterim biçimindeyse, doğrulama için ilgili araçları kullanılmalıdır, aksi takdirde doğrulama ve onaylama için kapsamlı bir tasarım incelemesi kullanılabilir.

Yapılandırılmış doğrulama yaklaşımıyla, gözden geçirenler bazı koşulları gözden kaçırmanın neden olabileceği hataları tespit edebilir. İyi bir tasarım incelemesi, iyi bir yazılım tasarımı, doğruluğu ve kalitesi için önemlidir.

Yazılım analizi ve tasarımı, gereksinim spesifikasyonunun uygulamaya dönüştürülmesine yardımcı olan tüm faaliyetleri içerir. Gereksinim özellikleri, yazılımdan tüm işlevsel ve işlevsel olmayan beklentileri belirtir. Bu gereksinim özellikleri, bilgisayarın hiçbir ilgisi olmayan, insan tarafından okunabilir ve anlaşılabilir belgeler şeklinde gelir.

Yazılım analizi ve tasarımı, insan tarafından okunabilir gereksinimlerin gerçek koda dönüştürülmesine yardımcı olan ara aşamadır.

Yazılım tasarımcıları tarafından kullanılan birkaç analiz ve tasarım aracını görelim:

Veri Akış Şeması

Veri akış diyagramı, bir bilgi sistemindeki veri akışının grafiksel temsilidir. Gelen veri akışını, giden veri akışını ve depolanan verileri tasvir edebilir. DFD, verilerin sistemden nasıl geçtiğinden bahsetmez.

DFD ve Akış Şeması arasında belirgin bir fark vardır. Akış şeması, program modüllerindeki kontrol akışını gösterir. DFD'ler, sistemdeki çeşitli düzeylerdeki veri akışını gösterir. DFD herhangi bir kontrol veya dal öğesi içermez.

DFD Türleri

Veri Akış Şemaları Mantıksal veya Fizikseldir.

• Logical DFD - Bu tür DFD, sistem sürecine ve sistemdeki veri akışına odaklanır.Örneğin bir Bankacılık yazılım sisteminde, verilerin farklı varlıklar arasında nasıl taşındığı.
• Physical DFD- Bu tür DFD, veri akışının sistemde gerçekte nasıl uygulandığını gösterir. Daha spesifik ve uygulamaya yakındır.

DFD Bileşenleri

DFD, aşağıdaki bileşen setini kullanarak veri kaynağını, hedefi, depolamayı ve akışını temsil edebilir -

• Entities- Varlıklar, bilgi verilerinin kaynağı ve hedefidir. Varlıklar, kendi adlarıyla birlikte bir dikdörtgenle temsil edilir.
• Process - Veriler üzerinde gerçekleştirilen faaliyetler ve eylemler, Daire veya Yuvarlak kenarlı dikdörtgenlerle temsil edilir.
• Data Storage - Veri depolamanın iki çeşidi vardır - ya iki küçük kenarı olmayan bir dikdörtgen olarak ya da yalnızca bir kenarı eksik olan açık kenarlı bir dikdörtgen olarak gösterilebilir.
• Data Flow- Verilerin hareketi sivri oklarla gösterilmiştir. Veri hareketi, kaynak olarak ok tabanından hedef olarak okun başına doğru gösterilir.

DFD Seviyeleri

• Level 0- En yüksek soyutlama seviyesi DFD, tüm bilgi sistemini temeldeki tüm ayrıntıları gizleyen tek bir şema olarak gösteren Seviye 0 DFD olarak bilinir. Düzey 0 DFD'ler, bağlam düzeyinde DFD'ler olarak da bilinir.

• Level 1- Düzey 0 DFD, daha özel Düzey 1 DFD'ye bölünmüştür. Seviye 1 DFD, sistemdeki temel modülleri ve çeşitli modüller arasındaki veri akışını gösterir. Seviye 1 DFD ayrıca temel süreçlerden ve bilgi kaynaklarından bahseder.


• Level 2 - Bu seviyede DFD, Seviye 1'de belirtilen modüllerin içinde verilerin nasıl aktığını gösterir.

  Daha yüksek seviyeli DFD'ler, istenen spesifikasyon seviyesine ulaşılmadıkça daha derin bir anlayış seviyesine sahip daha spesifik daha düşük seviyeli DFD'lere dönüştürülebilir.

Yapı Grafikleri

Yapı şeması, Veri Akış Şemasından türetilen bir grafiktir. Sistemi DFD'den daha detaylı temsil eder. Tüm sistemi en düşük işlevsel modüllere ayırır, sistemin her modülünün işlevlerini ve alt işlevlerini DFD'den daha ayrıntılı olarak açıklar.

Yapı şeması, modüllerin hiyerarşik yapısını temsil eder. Her katmanda belirli bir görev gerçekleştirilir.

Yapı çizelgelerinin yapımında kullanılan semboller:

• Module- Süreci veya alt rutini veya görevi temsil eder. Bir kontrol modülü, birden fazla alt modüle dallanır. Kitaplık Modülleri yeniden kullanılabilir ve herhangi bir modülden çağrılabilir.
  
• Condition- Modülün tabanında küçük bir elmas ile temsil edilir. Kontrol modülünün bazı koşullara göre alt rutinden herhangi birini seçebileceğini gösterir.
  
• Jump - Kontrolün alt modülün ortasına atlayacağını göstermek için modülün içini işaret eden bir ok gösterilir.
  
• Loop- Eğri bir ok, modüldeki döngüyü temsil eder. Tüm alt modüller, modülün döngü tekrarlı yürütmesi kapsamındadır.
  
• Data flow - Sonunda boş daire bulunan yönlendirilmiş bir ok, veri akışını temsil eder.
  
• Control flow - Sonunda içi dolu daire bulunan yönlendirilmiş bir ok, kontrol akışını temsil eder.
  

HIPO Diyagramı

HIPO (Hiyerarşik Giriş İşlem Çıkışı) diyagramı, sistemi analiz etmek ve dokümantasyon araçlarını sağlamak için iki organize yöntemin birleşimidir. HIPO modeli, 1970 yılında IBM tarafından geliştirilmiştir.

HIPO diyagramı, yazılım sistemindeki modüllerin hiyerarşisini temsil eder. Analist, sistem işlevlerinin üst düzey görünümünü elde etmek için HIPO diyagramını kullanır. İşlevleri hiyerarşik bir şekilde alt işlevlere ayırır. Sistem tarafından gerçekleştirilen işlevleri gösterir.

HIPO diyagramları dokümantasyon amaçlı iyidir. Grafiksel gösterimleri, tasarımcıların ve yöneticilerin sistem yapısı hakkında resimli fikir edinmelerini kolaylaştırır.

Bir modüldeki kontrol ve veri akışını gösteren IPO (Giriş İşlem Çıkışı) diyagramının aksine, HIPO veri akışı veya kontrol akışı hakkında herhangi bir bilgi sağlamaz.

Misal

HIPO diyagramının her iki bölümü, Hiyerarşik sunum ve IPO Şeması, yazılım programının yapı tasarımı ve bunların dokümantasyonu için kullanılır.

Yapılandırılmış İngilizce

Çoğu programcı, yazılımın büyük resminin farkında değildir, bu nedenle yalnızca yöneticilerinin onlara yapmalarını söylediklerine güvenirler. Doğru ancak hızlı kod geliştirmek için programcılara doğru bilgi sağlamak yüksek yazılım yönetiminin sorumluluğundadır.

Grafikler veya diyagramlar kullanan diğer yöntem biçimleri bazen farklı kişiler tarafından farklı yorumlanabilir.

Bu nedenle, yazılımın analistleri ve tasarımcıları Yapılandırılmış İngilizce gibi araçlar ortaya çıkarır. Kodlamak için neyin gerekli olduğu ve nasıl kodlanacağının açıklamasından başka bir şey değildir. Yapılandırılmış İngilizce, programcının hatasız kod yazmasına yardımcı olur.

Grafikler veya diyagramlar kullanan diğer yöntem biçimleri bazen farklı kişiler tarafından farklı yorumlanabilir. Burada, hem Yapılandırılmış İngilizce hem de Sözde Kod bu anlayış boşluğunu azaltmaya çalışır.

Yapılandırılmış İngilizce, yapılandırılmış programlama paradigmasında düz İngilizce kelimeler kullanır. Nihai kod değil, kodlamak için neyin gerekli olduğu ve nasıl kodlanacağı bir tür tanımlamadır. Aşağıdakiler, yapısal programlamanın bazı simgeleridir.

IF-THEN-ELSE,  
DO-WHILE-UNTIL

Analist, Veri Sözlüğünde depolanan aynı değişkeni ve veri adını kullanır, bu da kodu yazmayı ve anlamayı çok daha basit hale getirir.

Misal

Çevrimiçi alışveriş ortamında aynı Müşteri Kimlik Doğrulaması örneğini alıyoruz. Müşterinin kimliğini doğrulamaya yönelik bu prosedür, Yapılandırılmış İngilizce'de şu şekilde yazılabilir:

Enter Customer_Name
SEEK Customer_Name in Customer_Name_DB file
IF Customer_Name found THEN
   Call procedure USER_PASSWORD_AUTHENTICATE()
ELSE
   PRINT error message
   Call procedure NEW_CUSTOMER_REQUEST()
ENDIF

Yapılandırılmış İngilizce ile yazılan kod, daha çok günlük konuşulan İngilizce'ye benzer. Doğrudan bir yazılım kodu olarak uygulanamaz. Yapılandırılmış İngilizce, programlama dilinden bağımsızdır.

Sözde Kod

Sözde kod, programlama diline daha yakın yazılır. Yorum ve açıklamalarla dolu artırılmış programlama dili olarak düşünülebilir.

Sözde kod değişken bildiriminden kaçınır, ancak C, Fortran, Pascal vb. Gibi bazı gerçek programlama dillerinin yapıları kullanılarak yazılırlar.

Sözde kod, Yapılandırılmış İngilizce'den daha fazla programlama detayı içerir. Sanki bir bilgisayar kodu çalıştırıyormuş gibi görevi gerçekleştirmek için bir yöntem sağlar.

Misal

Fibonacci'yi n sayıya kadar yazdırmak için program.

void function Fibonacci
Get value of n;
Set value of a to 1;
Set value of b to 1;
Initialize I to 0
for (i=0; i< n; i++)
{
   if a greater than b 
   {
      Increase b by a;
      Print b;
   } 
   else if b greater than a
   {
      increase a by b;
      print a;
   }
}

Karar Tabloları

Karar tablosu, yapılandırılmış bir tablo formatında koşulları ve bunları ele almak için alınacak ilgili eylemleri temsil eder.

Hataları ayıklamak ve hataları önlemek için güçlü bir araçtır. Benzer bilgileri tek bir tabloda gruplandırmaya yardımcı olur ve ardından tabloları birleştirerek kolay ve rahat karar verme sağlar.

Karar Tablosu Oluşturma

Karar tablosunu oluşturmak için geliştiricinin temel dört adımı uygulaması gerekir:

• Ele alınacak tüm olası koşulları tanımlayın
• Tanımlanan tüm koşullar için eylemleri belirleyin
• Olası maksimum kural oluştur
• Her kural için eylem tanımlayın

Karar Tabloları son kullanıcılar tarafından doğrulanmalıdır ve son zamanlarda yinelenen kurallar ve eylemler ortadan kaldırılarak basitleştirilebilir.

Misal

İnternet bağlantımızla ilgili günlük soruna basit bir örnek verelim. İnterneti başlatırken ortaya çıkabilecek tüm sorunları ve bunların olası çözümlerini belirleyerek başlıyoruz.

Tüm olası sorunları sütun koşulları altında ve olası eylemleri Eylemler sütununda listeliyoruz.

	Koşullar / İşlemler	Kurallar
Koşullar	Bağlı Şovlar	N	N	N	N	Y	Y	Y	Y
	Ping Çalışıyor	N	N	Y	Y	N	N	Y	Y
	Web sitesini açar	Y	N	Y	N	Y	N	Y	N
Hareketler	Ağ kablosunu kontrol edin	X
	İnternet yönlendiricisini kontrol edin	X				X	X	X
	Web Tarayıcısını Yeniden Başlatın							X
	Servis sağlayıcıyla iletişime geçin		X	X	X	X	X	X
	Eylem yapma

Tablo: Karar Tablosu - Şirket İçi İnternet Sorunlarını Giderme

Varlık-İlişki Modeli

Varlık-İlişki modeli, gerçek dünya varlıkları kavramına ve aralarındaki ilişkiye dayanan bir veritabanı modeli türüdür. Gerçek dünya senaryosunu ER veritabanı modeliyle eşleştirebiliriz. ER Modeli, nitelikleriyle, bir dizi kısıtlamayla ve aralarındaki ilişkiyle bir dizi varlık oluşturur.

ER Modeli, veri tabanının kavramsal tasarımı için en iyi şekilde kullanılır. ER Modeli şu şekilde temsil edilebilir:

• Entity - ER Modelindeki bir varlık, gerçek dünya varlığıdır ve bazı özellikleri vardır. attributes. Her öznitelik, adı verilen karşılık gelen değer kümesiyle tanımlanır.domain.

  Örneğin, bir okul veritabanı düşünün. Burada öğrenci bir varlıktır. Öğrencinin adı, kimliği, yaşı ve sınıfı gibi çeşitli özellikleri vardır.

• Relationship - Varlıklar arasındaki mantıksal ilişkiye denir relationship. İlişkiler, varlıklar ile çeşitli şekillerde eşleştirilir. Eşleme kardinaliteleri, iki varlık arasındaki ilişkilerin sayısını tanımlar.

  Değerleri Eşleme:

  • bire bir
  • birden çoğa
  • çoktan bire
  • çoktan çoğa

Bilgi sözlüğü

Veri sözlüğü, verilerle ilgili bilgilerin merkezi olarak toplanmasıdır. Verinin anlamını ve kaynağını, diğer verilerle ilişkisini, kullanım için veri formatı vb. Depolar. Veri sözlüğü, kullanıcı ve yazılım tasarımcılarını kolaylaştırmak için tüm isimlerin titiz tanımlarına sahiptir.

Veri sözlüğüne genellikle meta veri (verilerle ilgili veriler) havuzu olarak atıfta bulunulur. Yazılım programının DFD (Veri Akış Şeması) modeli ile birlikte oluşturulur ve DFD her değiştirildiğinde veya güncellendiğinde güncellenmesi beklenir.

Veri Sözlüğünün Gerekliliği

Verilere, yazılım tasarlanırken ve uygulanırken veri sözlüğü aracılığıyla başvurulur. Veri sözlüğü herhangi bir belirsizlik olasılığını ortadan kaldırır. Programın her yerinde aynı nesne referansını kullanırken programcıların ve tasarımcıların çalışmalarının senkronize olmasına yardımcı olur.

Veri sözlüğü, tek bir yerde tüm veritabanı sistemi için bir dokümantasyon yolu sağlar. DFD'nin doğrulanması, veri sözlüğü kullanılarak gerçekleştirilir.

İçindekiler

Veri sözlüğü aşağıdakiler hakkında bilgi içermelidir

• Veri akışı
• Veri yapısı
• Veri Öğeleri
• Veri Depoları
• Veri işleme

Veri Akışı, daha önce incelenen ve açıklandığı gibi cebirsel formda temsil edilen DFD'ler aracılığıyla tanımlanır.

=	Oluşan
{}	Tekrarlama
()	İsteğe bağlı
+	Ve
[/]	Veya

Misal

Adres = Ev No + (Cadde / Bölge) + Şehir + Eyalet

Kurs Kimliği = Kurs Numarası + Kurs Adı + Kurs Seviyesi + Kurs Notları

Veri Öğeleri

Veri öğeleri, Veri ve Kontrol Öğelerinin Adından ve açıklamalarından, Dahili veya Harici veri depolarından vb. Aşağıdaki ayrıntılarla oluşur:

• Birincil Ad
• İkincil Ad (Takma Ad)
• Kullanım durumu (Nasıl ve nerede kullanılır)
• İçerik Açıklaması (Gösterim vb.)
• Tamamlayıcı Bilgiler (önceden ayarlanmış değerler, kısıtlamalar vb.)

Bilgi deposu

Verilerin sisteme girdiği ve sistem dışında var olduğu yerden bilgileri depolar. Veri Deposu şunları içerebilir:

• Files
  • Yazılımın içinde.
  • Yazılımın dışında ama aynı makinede.
  • Yazılım ve sistem dışında, farklı makinelerde bulunur.
• Tables
  • Adlandırma kuralı
  • Mülkiyet indeksleniyor

Veri işleme

İki tür Veri İşleme vardır:

• Logical: Kullanıcı gördüğü gibi
• Physical: Yazılımın gördüğü gibi

Yazılım tasarımı, yazılım gereksinimlerini yazılım uygulamasına kavramsallaştırma sürecidir. Yazılım tasarımı, kullanıcı gereksinimlerini zorluk olarak alır ve en uygun çözümü bulmaya çalışır. Yazılım kavramsallaştırılırken, amaçlanan çözümü uygulamak için mümkün olan en iyi tasarımı bulmak için bir plan hazırlanır.

Yazılım tasarımının birden çok çeşidi vardır. Bunları kısaca inceleyelim:

Yapısal Tasarım

Yapılandırılmış tasarım, problemin iyi organize edilmiş çözüm unsurlarına göre kavramsallaştırılmasıdır. Temelde çözüm tasarımı ile ilgilidir. Yapılandırılmış tasarımın faydası, sorunun nasıl çözüldüğünün daha iyi anlaşılmasını sağlamasıdır. Yapılandırılmış tasarım, tasarımcının soruna daha doğru bir şekilde konsantre olmasını da kolaylaştırır.

Yapılandırılmış tasarım çoğunlukla, bir sorunun birkaç küçük soruna bölündüğü ve her küçük sorunun, tüm sorun çözülene kadar ayrı ayrı çözüldüğü 'böl ve yönet' stratejisine dayanır.

Küçük problem parçaları çözüm modülleri ile çözülür. Yapılandırılmış tasarım, kesin çözüme ulaşmak için bu modüllerin iyi organize edilmesini vurgular.

Bu modüller hiyerarşi içinde düzenlenmiştir. Birbirleriyle iletişim kurarlar. İyi yapılandırılmış bir tasarım, her zaman birden fazla modül arasındaki iletişim için bazı kuralları izler, yani -

Cohesion - işlevsel olarak ilişkili tüm öğelerin gruplanması.

Coupling - farklı modüller arasında iletişim.

İyi yapılandırılmış bir tasarım, yüksek kohezyon ve düşük bağlantı düzenlemelerine sahiptir.

Fonksiyon Odaklı Tasarım

İşlev odaklı tasarımda sistem, işlevler olarak bilinen birçok küçük alt sistemden oluşur. Bu işlevler, sistemde önemli görevleri yerine getirebilir. Sistem, tüm işlevlerin üstten görünümü olarak kabul edilir.

İşlev odaklı tasarım, böl ve yönet metodolojisinin kullanıldığı yapısal tasarımın bazı özelliklerini devralır.

Bu tasarım mekanizması, tüm sistemi daha küçük işlevlere böler, bu da bilgiyi ve işleyişini gizleyerek soyutlama araçları sağlar. Bu işlevsel modüller, bilgi aktarımı ve küresel olarak mevcut bilgileri kullanarak kendi aralarında bilgi paylaşabilir.

Fonksiyonların diğer bir özelliği, bir program bir fonksiyonu çağırdığında, fonksiyonun bazen diğer modüller tarafından kabul edilemeyen programın durumunu değiştirmesidir. İşlev odaklı tasarım, sistem durumunun önemli olmadığı ve program / işlevlerin bir durum yerine girdi üzerinde çalıştığı durumlarda iyi çalışır.

Dizayn süreci

• Tüm sistem, veri akış diyagramı ile verilerin sistemde nasıl aktığı olarak görülmektedir.
• DFD, işlevlerin verileri ve tüm sistemin durumunu nasıl değiştirdiğini gösterir.
• Sistemin tamamı, mantıksal olarak, sistemdeki çalışmaları temelinde işlevler olarak bilinen daha küçük birimlere bölünür.
• Her bir işlev daha sonra geniş olarak açıklanır.

Nesneye Yönelik Tasarım

Nesneye yönelik tasarım, yazılım sisteminde yer alan işlevler yerine varlıklar ve özellikleri etrafında çalışır. Bu tasarım stratejileri, varlıklara ve özelliklerine odaklanır. Tüm yazılım çözümü kavramı, ilgili kuruluşlar etrafında döner.

Nesneye Yönelik Tasarımın önemli kavramlarını görelim:

• Objects - Çözüm tasarımına dahil olan tüm varlıklar nesneler olarak bilinir. Örneğin, kişi, bankalar, şirket ve müşteriler nesne olarak kabul edilir. Her varlığın kendisiyle ilişkili bazı öznitelikleri vardır ve öznitelikler üzerinde gerçekleştirmek için bazı yöntemleri vardır.

• Classes - Bir sınıf, bir nesnenin genelleştirilmiş bir açıklamasıdır. Bir nesne, bir sınıfın bir örneğidir. Sınıf, bir nesnenin sahip olabileceği tüm nitelikleri ve nesnenin işlevselliğini tanımlayan yöntemleri tanımlar.

  Çözüm tasarımında öznitelikler değişkenler olarak saklanır ve işlevler yöntemler veya prosedürler aracılığıyla tanımlanır.

• Encapsulation - OOD'de, öznitelikler (veri değişkenleri) ve yöntemler (veriler üzerinde işlem) birlikte paketlenir, kapsülleme olarak adlandırılır. Kapsülleme, yalnızca bir nesnenin önemli bilgilerini bir araya getirmekle kalmaz, aynı zamanda dış dünyadan veri ve yöntemlere erişimi de kısıtlar. Buna bilgi gizleme denir.
• Inheritance - OOD, benzer sınıfların, alt veya alt sınıfların izin verilen değişkenleri ve yöntemleri hemen süper sınıflarından içe aktarabileceği, uygulayabileceği ve yeniden kullanabileceği hiyerarşik bir şekilde yığılmasına izin verir. OOD'nin bu özelliği kalıtım olarak bilinir. Bu, belirli sınıfları tanımlamayı ve belirli sınıflardan genelleştirilmiş sınıflar oluşturmayı kolaylaştırır.
• Polymorphism - OOD dilleri, benzer görevleri gerçekleştiren ancak bağımsız değişkenlerde farklılık gösteren yöntemlerin aynı adın atanabileceği bir mekanizma sağlar. Buna, farklı türler için görevler gerçekleştiren tek bir arayüze izin veren polimorfizm denir. İşlevin nasıl çağrıldığına bağlı olarak, kodun ilgili bölümü çalıştırılır.

Dizayn süreci

Yazılım tasarım süreci, iyi tanımlanmış adımlar dizisi olarak algılanabilir. Tasarım yaklaşımına göre değişiklik gösterse de (işlev odaklı veya nesne yönelimli, yine de aşağıdaki adımlar dahil olabilir:

• Gereksinimden veya daha önce kullanılan sistem ve / veya sistem sıra diyagramından bir çözüm tasarımı oluşturulur.
• Nesneler, öznitelik özelliklerindeki benzerlik adına tanımlanır ve sınıflar halinde gruplandırılır.
• Sınıf hiyerarşisi ve aralarındaki ilişki tanımlanır.
• Uygulama çerçevesi tanımlanmıştır.

Yazılım Tasarım Yaklaşımları

Yazılım tasarımı için iki genel yaklaşım şunlardır:

Yukarıdan Aşağıya Tasarım

Bir sistemin birden fazla alt sistemden oluştuğunu ve birkaç bileşen içerdiğini biliyoruz. Ayrıca, bu alt sistemler ve bileşenler kendi alt sistem ve bileşenlerine sahip olabilir ve sistemde hiyerarşik yapı oluşturur.

Yukarıdan aşağıya tasarım, tüm yazılım sistemini tek bir varlık olarak alır ve daha sonra, bazı özelliklere dayalı olarak birden fazla alt sistem veya bileşen elde etmek için onu ayrıştırır. Her bir alt sistem veya bileşen daha sonra bir sistem olarak işlem görür ve daha da ayrıştırılır. Bu süreç, yukarıdan aşağıya hiyerarşideki en düşük sistem seviyesi elde edilene kadar çalışmaya devam eder.

Yukarıdan aşağıya tasarım, genelleştirilmiş bir sistem modeliyle başlar ve daha spesifik olan kısmını tanımlamaya devam eder. Tüm bileşenler bir araya geldiğinde tüm sistem ortaya çıkar.

Yukarıdan aşağıya tasarım, yazılım çözümünün sıfırdan tasarlanması gerektiğinde ve belirli ayrıntılar bilinmediğinde daha uygundur.

Aşağıdan Yukarıya Tasarım

Aşağıdan yukarıya tasarım modeli, en özel ve temel bileşenlerle başlar. Temel veya daha düşük seviyeli bileşenleri kullanarak daha yüksek seviyeli bileşenler oluşturmaya devam eder. İstenilen sistem tek bir bileşen olarak gelişene kadar daha yüksek seviyeli bileşenler oluşturmaya devam eder. Her yüksek seviyede, soyutlama miktarı artar.

Yeni sistemde temel ilkelerin kullanılabileceği bazı mevcut sistemlerden bir sistemin oluşturulması gerektiğinde aşağıdan yukarıya strateji daha uygundur.

Hem yukarıdan aşağıya hem de aşağıdan yukarıya yaklaşımlar ayrı ayrı pratik değildir. Bunun yerine, her ikisinin de iyi bir kombinasyonu kullanılır.

Kullanıcı arayüzü, kullanıcının yazılımı kullanmak için etkileşimde bulunduğu ön uç uygulama görünümüdür. Kullanıcı, kullanıcı arayüzü aracılığıyla yazılımı ve donanımı yönetebilir ve kontrol edebilir. Günümüzde bilgisayarlardan, cep telefonlarından, arabalardan, müzik çalarlardan, uçaklardan, gemilerden vb. Dijital teknolojinin olduğu hemen hemen her yerde kullanıcı arayüzü bulunmaktadır.

Kullanıcı arayüzü, yazılımın bir parçasıdır ve kullanıcıya yazılıma ilişkin içgörü sağlamasının bekleneceği şekilde tasarlanmıştır. UI, insan-bilgisayar etkileşimi için temel bir platform sağlar.

Kullanıcı arayüzü, temel donanım ve yazılım kombinasyonuna bağlı olarak grafik, metin tabanlı, ses-video tabanlı olabilir. UI, donanım veya yazılım veya her ikisinin bir kombinasyonu olabilir.

Yazılım, kullanıcı arayüzü aşağıdaki durumlarda daha popüler hale gelir:

• Attractive
• Kullanımı kolay
• Kısa sürede duyarlı
• Anlaşılması açık
• Tüm arayüz ekranlarında tutarlı

Kullanıcı arayüzü genel olarak iki kategoriye ayrılmıştır:

• Komut satırı arayüzü
• Grafiksel kullanıcı arayüzü

Komut Satırı Arayüzü (CLI)

CLI, video görüntüleme monitörleri ortaya çıkana kadar bilgisayarlarla harika bir etkileşim aracı olmuştur. CLI, birçok teknik kullanıcı ve programcının ilk tercihidir. CLI, bir yazılımın kullanıcılarına sağlayabileceği minimum arayüzdür.

CLI, kullanıcının komutu yazdığı ve sisteme beslediği yer olan bir komut istemi sağlar. Kullanıcının komut sözdizimini ve kullanımını hatırlaması gerekir. Daha önceki CLI, kullanıcı hatalarını etkin bir şekilde ele alacak şekilde programlanmamıştı.

Bir komut, sistem tarafından yürütülmesi beklenen talimat setine yönelik metin tabanlı bir referanstır. Kullanıcının çalışmasını kolaylaştıran makrolar, komut dosyaları gibi yöntemler vardır.

CLI, GUI'ye kıyasla daha az miktarda bilgisayar kaynağı kullanır.

CLI Öğeleri

Metin tabanlı bir komut satırı arabirimi aşağıdaki öğelere sahip olabilir:

• Command Prompt- Çoğunlukla kullanıcının çalıştığı bağlamı gösteren metin tabanlı bir bilgilendiricidir. Yazılım sistemi tarafından üretilir.

• Cursor- Yazarken karakterin konumunu temsil etmek için küçük bir yatay çizgi veya satır yüksekliğinde dikey bir çubuktur. İmleç çoğunlukla yanıp sönme durumunda bulunur. Kullanıcı bir şeyler yazarken veya silerken hareket eder.

• Command- Komut, çalıştırılabilir bir talimattır. Bir veya daha fazla parametresi olabilir. Komut yürütmedeki çıktı, ekranda satır içi olarak gösterilir. Çıktı üretildiğinde, bir sonraki satırda komut istemi görüntülenir.

Grafiksel kullanıcı arayüzü

Grafik Kullanıcı Arayüzü, kullanıcıya sistemle etkileşim kurması için grafiksel araçlar sağlar. GUI, hem donanım hem de yazılımın birleşimi olabilir. Kullanıcı GUI kullanarak yazılımı yorumlar.

Tipik olarak GUI, CLI'ninkinden daha fazla kaynak tüketir. Gelişen teknoloji ile programcılar ve tasarımcılar, daha verimli, doğru ve hızlı çalışan karmaşık GUI tasarımları oluşturur.

GUI Öğeleri

GUI, yazılım veya donanımla etkileşim kurmak için bir dizi bileşen sağlar.

Her grafik bileşen, sistemle çalışmanın bir yolunu sağlar. Bir GUI sistemi aşağıdaki gibi aşağıdaki unsurlara sahiptir:

• Window- Uygulama içeriğinin görüntülendiği bir alan. Pencere dosya yapısını temsil ediyorsa, bir penceredeki içerik simgeler veya listeler şeklinde görüntülenebilir. Bir kullanıcının bir keşif penceresinde dosya sisteminde gezinmesi daha kolaydır. Windows ekran boyutuna küçültülebilir, yeniden boyutlandırılabilir veya büyütülebilir. Ekranda herhangi bir yere taşınabilirler. Bir pencere aynı uygulamanın alt pencere adı verilen başka bir penceresini içerebilir.

• Tabs - Bir uygulama kendisinin birden fazla örneğinin yürütülmesine izin veriyorsa, bunlar ekranda ayrı pencereler olarak görünür. Tabbed Document Interfaceaynı pencerede birden çok belge açmaya geldi. Bu arayüz ayrıca uygulamada tercih panelini görüntülemeye yardımcı olur. Tüm modern web tarayıcıları bu özelliği kullanır.

• Menu- Menü, birlikte gruplanmış ve uygulama penceresinin içinde görünür bir yere (genellikle üstte) yerleştirilmiş standart komutlar dizisidir. Menü, fare tıklamalarında görünecek veya gizlenecek şekilde programlanabilir.

• Icon- Bir simge, ilişkili bir uygulamayı temsil eden küçük bir resimdir. Bu simgelere tıklandığında veya çift tıklandığında uygulama penceresi açılır. Simge, bir sisteme yüklenmiş uygulamaları ve programları küçük resimler biçiminde görüntüler.

• Cursor- Fare, dokunmatik yüzey, dijital kalem gibi etkileşimli cihazlar GUI'de imleç olarak temsil edilir. Ekrandaki imleç, donanımdaki talimatları neredeyse gerçek zamanlı olarak izler. İmleçler ayrıca GUI sistemlerinde işaretçiler olarak adlandırılır. Menüleri, pencereleri ve diğer uygulama özelliklerini seçmek için kullanılırlar.

Uygulamaya özel GUI bileşenleri

Bir uygulamanın GUI'si listelenen GUI öğelerinin birini veya birkaçını içerir:

• Application Window - Çoğu uygulama penceresi, işletim sistemleri tarafından sağlanan yapıları kullanır, ancak birçoğu uygulamanın içeriğini içermek için kendi müşteri tarafından oluşturulan pencereleri kullanır.

• Dialogue Box - Kullanıcı için mesaj içeren ve bazı işlemlerin yapılmasını talep eden bir alt penceredir. Örneğin: Uygulama, kullanıcıdan bir dosyayı silmek için onay almak üzere bir diyalog oluşturur.

  

• Text-Box - Kullanıcının metin tabanlı verileri yazması ve girmesi için bir alan sağlar.

• Buttons - Gerçek hayattaki düğmeleri taklit ederler ve yazılıma girdi göndermek için kullanılırlar.

  

• Radio-button- Seçim için mevcut seçenekleri görüntüler. Tüm sunulanlar arasından yalnızca biri seçilebilir.

• Check-box- Liste kutusuna benzer işlevler. Bir seçenek belirlendiğinde, kutu işaretli olarak işaretlenir. Onay kutuları ile temsil edilen birden çok seçenek seçilebilir.

• List-box - Seçim için mevcut öğelerin listesini sağlar. Birden fazla öğe seçilebilir.

  

Diğer etkileyici GUI bileşenleri şunlardır:

• Sliders
• Combo-box
• Data-grid
• Açılır liste

Kullanıcı Arayüzü Tasarım Faaliyetleri

Kullanıcı arayüzünü tasarlamak için gerçekleştirilen bir dizi faaliyet vardır. GUI tasarım ve uygulama süreci, SDLC'ye benzer. Şelale, Yinelemeli veya Spiral Model arasında herhangi bir model GUI uygulaması için kullanılabilir.

GUI tasarımı ve geliştirmesi için kullanılan bir model, bu GUI'ye özgü adımları yerine getirmelidir.

• GUI Requirement Gathering- Tasarımcılar, GUI'nin tüm işlevsel ve işlevsel olmayan gereksinimlerinin bir listesini almak isteyebilirler. Bu, kullanıcıdan ve mevcut yazılım çözümünden alınabilir.

• User Analysis- Tasarımcı, yazılım GUI'sini kimin kullanacağını araştırır. Tasarım detayları kullanıcının bilgi ve yetkinlik düzeyine göre değiştiği için hedef kitle önemlidir. Kullanıcı teknik bilgili ise, gelişmiş ve karmaşık GUI dahil edilebilir. Acemi bir kullanıcı için, yazılımın nasıl yapılacağı hakkında daha fazla bilgi yer almaktadır.

• Task Analysis- Tasarımcılar, yazılım çözümü tarafından hangi görevin yapılması gerektiğini analiz etmelidir. Burada GUI'de nasıl yapılacağı önemli değil. Görevler, bir ana görevi alarak ve onu daha küçük alt görevlere bölerek hiyerarşik bir şekilde temsil edilebilir. Görevler, GUI sunumu için hedefler sağlar. Alt görevler arasındaki bilgi akışı, yazılımdaki GUI içeriğinin akışını belirler.

• GUI Design & implementation- Tasarımcılar, gereksinimler, görevler ve kullanıcı ortamı hakkında bilgi aldıktan sonra, GUI'yi tasarlar ve koda uygular ve GUI'yi arka planda çalışan veya kukla yazılımla yerleştirir. Daha sonra geliştiriciler tarafından kendi kendine test edilir.

• Testing- GUI testi çeşitli şekillerde yapılabilir. Kurum içi denetim yapabilir, kullanıcıların doğrudan katılımı ve beta sürümün yayınlanması bunlardan birkaçıdır. Test kullanılabilirlik, uyumluluk, kullanıcı kabulü vb. İçerebilir.

GUI Uygulama Araçları

Tasarımcıların bir fare tıklamasıyla tüm GUI'yi oluşturabilecekleri çeşitli araçlar mevcuttur. Bazı araçlar yazılım ortamına (IDE) gömülebilir.

GUI uygulama araçları, güçlü bir dizi GUI denetimi sağlar. Yazılım özelleştirme için tasarımcılar kodu buna göre değiştirebilir.

Farklı kullanım ve platforma göre GUI araçlarının farklı segmentleri vardır.

Misal

Mobil GUI, Bilgisayar GUI, Dokunmatik Ekran GUI vb. GUI oluşturmak için kullanışlı olan birkaç aracın listesi:

• FLUID
• AppInventor (Android)
• LucidChart
• Wavemaker
• Görsel stüdyo

Kullanıcı Arayüzü Altın kuralları

Aşağıdaki kuralların, Shneiderman ve Plaisant tarafından kitaplarında (Designing the User Interface) açıklanan GUI tasarımı için altın kurallar olduğu belirtilmiştir.

• Strive for consistency- Benzer durumlarda tutarlı eylem dizileri gerekli olmalıdır. Bilgi istemlerinde, menülerde ve yardım ekranlarında aynı terminoloji kullanılmalıdır. Tutarlı komutlar baştan sona kullanılmalıdır.

• Enable frequent users to use short-cuts- Kullanıcının etkileşim sayısını azaltma isteği kullanım sıklığı ile artar. Kısaltmalar, işlev tuşları, gizli komutlar ve makro olanakları, uzman bir kullanıcı için çok faydalıdır.

• Offer informative feedback- Her operatör eylemi için bazı sistem geri bildirimleri olmalıdır. Sık ve küçük eylemler için yanıt mütevazı olmalı, seyrek ve büyük eylemler için ise yanıt daha önemli olmalıdır.

• Design dialog to yield closure- Eylem dizileri başlangıcı, ortası ve sonu olan gruplar halinde düzenlenmelidir. Bir grup eylemin tamamlanmasındaki bilgilendirici geri bildirim, operatörlere başarının tatmini, rahatlama duygusu, acil durum planlarını ve seçenekleri akıllarından bırakma sinyalini verir ve bu, bir sonraki için hazırlanmanın önündeki yolun açık olduğunu gösterir. eylemler grubu.

• Offer simple error handling- Sistemi mümkün olduğunca kullanıcının ciddi bir hata yapmayacağı şekilde tasarlayın. Bir hata yapılırsa, sistem bunu tespit edebilmeli ve hatayı ele almak için basit, anlaşılır mekanizmalar sunabilmelidir.

• Permit easy reversal of actions- Kullanıcı hataların geri alınabileceğini bildiği için bu özellik endişeyi giderir. Eylemlerin kolayca tersine çevrilmesi, bilinmeyen seçeneklerin keşfedilmesini teşvik eder. Tersinirlik birimleri tek bir eylem, bir veri girişi veya tam bir eylemler grubu olabilir.

• Support internal locus of control- Deneyimli operatörler, sistemden sorumlu oldukları ve sistemin eylemlerine yanıt verdiği hissini kuvvetle arzu ederler. Sistemi, kullanıcıları yanıt verenler yerine eylemlerin başlatıcısı yapacak şekilde tasarlayın.

• Reduce short-term memory load - Kısa süreli bellekte insan bilgisi işlemenin sınırlandırılması, ekranların basit tutulmasını, çoklu sayfa görüntülerinin birleştirilmesini, pencere hareket sıklığının azaltılmasını ve kodlar, anımsatıcılar ve eylem dizileri için yeterli eğitim süresinin ayrılmasını gerektirir.

Karmaşıklık terimi, çok sayıda birbirine bağlı bağlantıya ve oldukça karmaşık yapılara sahip olayların veya şeylerin durumunu ifade eder. Yazılım programlamasında, yazılımın tasarımı gerçekleştirildikçe, eleman sayısı ve bunların ara bağlantıları kademeli olarak çok büyük hale gelir ve bu da bir anda anlaşılması çok zor hale gelir.

Yazılım tasarımının karmaşıklığını, karmaşıklık ölçütlerini ve önlemlerini kullanmadan değerlendirmek zordur. Üç önemli yazılım karmaşıklığı ölçüsünü görelim.

Halstead'in Karmaşıklık Ölçüleri

1977'de, Bay Maurice Howard Halstead, yazılım karmaşıklığını ölçmek için metrikleri tanıttı. Halstead'in ölçümleri, programın gerçek uygulamasına ve doğrudan kaynak kodundan işlenenlerden ve işlenenlerden statik olarak hesaplanan ölçümlerine bağlıdır. C / C ++ / Java kaynak kodu için test süresi, kelime bilgisi, boyut, zorluk, hatalar ve çabaların değerlendirilmesine olanak sağlar.

Halstead'e göre, "Bir bilgisayar programı, operatörler veya işlenenler olarak sınıflandırılabilen bir simge koleksiyonu olarak kabul edilen bir algoritmanın uygulamasıdır". Halstead ölçümleri, bir programı operatörler dizisi ve bunlarla ilişkili işlenenler olarak düşünür.

Modülün karmaşıklığını kontrol etmek için çeşitli göstergeler tanımlar.

Parametre	Anlam
n1	Benzersiz operatörlerin sayısı
n2	Benzersiz işlenenlerin sayısı
N1	Operatörlerin toplam oluşum sayısı
N2	İşlenenlerin toplam oluşum sayısı

Metrik Görüntüleyici'de karmaşıklık ayrıntılarını görüntülemek için kaynak dosyayı seçtiğimizde, Metrik Raporunda aşağıdaki sonuç görülür:

Metrik	Anlam	Matematiksel Gösterim
n	Kelime bilgisi	n1 + n2
N	Boyut	N1 + N2
V	Ses	Uzunluk * Log2 Kelime Bilgisi
D	Zorluk	(n1 / 2) * (N1 / n2)
E	Çabalar	Zorluk * Hacim
B	Hatalar	Hacim / 3000
T	Test süresi	Zaman = Çabalar / S, burada S = 18 saniye.

Siklomatik Karmaşıklık Ölçüleri

Her program, bazı görevleri gerçekleştirmek için yürütülecek ifadeleri ve hangi ifadelerin yürütülmesi gerektiğine karar veren diğer karar verme ifadelerini içerir. Bu karar verme yapıları programın akışını değiştirir.

Aynı boyuttaki iki programı karşılaştırırsak, daha fazla karar verme ifadesine sahip olan programın kontrolü sık sık atladığından daha karmaşık olacaktır.

McCabe, 1976'da, belirli bir yazılımın karmaşıklığını ölçmek için Siklomatik Karmaşıklık Ölçümü'nü önerdi. If-else, do-while, again-until, switch-case ve goto ifadeleri gibi programın karar verme yapılarına dayanan grafik tabanlı modeldir.

Akış kontrol grafiği oluşturma süreci:

• Programı, karar verme yapıları ile sınırlandırılmış daha küçük bloklar halinde kırın.
• Bu düğümlerin her birini temsil eden düğümler oluşturun.
• Düğümleri aşağıdaki şekilde bağlayın:

• Kontrol, blok i'den blok j'ye dalabilirse

  Yay çizin

• Çıkış düğümünden giriş düğümüne

  Bir yay çizin.

Bir program modülünün Siklomatik karmaşıklığını hesaplamak için aşağıdaki formülü kullanırız -

V(G) = e – n + 2

Where
e is total number of edges
n is total number of nodes

Yukarıdaki modülün Siklomatik karmaşıklığı

e = 10
n = 8
Cyclomatic Complexity = 10 - 8 + 2
                      = 4

P. Jorgensen'e göre, bir modülün Siklomatik Karmaşıklığı 10'u geçmemelidir.

İşlev Noktası

Yazılımın boyutunu ölçmek için yaygın olarak kullanılır. İşlev Noktası, sistem tarafından sağlanan işlevselliğe odaklanır. Yazılım karmaşıklığını ölçmek için sistemin özellikleri ve işlevselliği kullanılır.

Fonksiyon puanı, Harici Giriş, Harici Çıkış, Mantıksal Dahili Dosyalar, Harici Arayüz Dosyaları ve Harici Sorgu olarak adlandırılan beş parametreye göre hesaplanır. Yazılımın karmaşıklığını göz önünde bulundurmak için her parametre ayrıca basit, ortalama veya karmaşık olarak kategorize edilir.

Fonksiyon noktasının parametrelerini görelim:

Harici Giriş

Sisteme dışarıdan gelen her benzersiz giriş, harici giriş olarak kabul edilir. İki girişin aynı formatta olmaması gerektiğinden, girdinin benzersizliği ölçülür. Bu girdiler veri veya kontrol parametreleri olabilir.

• Simple - girdi sayısı düşükse ve daha az dahili dosyayı etkiliyorsa

• Complex - girdi sayısı yüksekse ve daha fazla dahili dosyayı etkiliyorsa

• Average - basit ve karmaşık arasında.

Harici Çıkış

Sistem tarafından sağlanan tüm çıktı türleri bu kategoride sayılır. Çıktı biçimi ve / veya işlemesi benzersizse çıktı benzersiz olarak kabul edilir.

• Simple - çıktı sayısı düşükse

• Complex - çıktı sayısı yüksekse

• Average - basit ve karmaşık arasında.

Mantıksal Dahili Dosyalar

Her yazılım sistemi, işlevsel bilgilerini korumak ve düzgün çalışması için dahili dosyaları saklar. Bu dosyalar sistemin mantıksal verilerini tutar. Bu mantıksal veriler hem işlevsel verileri hem de kontrol verilerini içerebilir.

• Simple - kayıt türü sayısı azsa

• Complex - kayıt türü sayısı yüksekse

• Average - basit ve karmaşık arasında.

Harici Arayüz Dosyaları

Yazılım sisteminin dosyalarını bazı harici yazılımlarla paylaşması gerekebilir veya dosyayı işlenmek üzere veya bir işleve parametre olarak aktarması gerekebilir. Tüm bu dosyalar, harici arayüz dosyaları olarak sayılır.

• Simple - paylaşılan dosyadaki kayıt türü sayısı azsa

• Complex - paylaşılan dosyadaki kayıt türü sayısı yüksekse

• Average - basit ve karmaşık arasında.

Harici Sorgulama

Sorgu, kullanıcının girdi olarak sorgulamak için bazı verileri gönderdiği ve sistemin kullanıcıya işlenen sorgulamanın çıktısı ile yanıt verdiği bir girdi ve çıktı kombinasyonudur. Bir sorgunun karmaşıklığı, Harici Giriş ve Harici Çıktıdan daha fazladır. Sorgunun, girdisi ve çıktısı biçim ve veri açısından benzersiz olması durumunda benzersiz olduğu söylenir.

• Simple - sorgu düşük işleme gerektiriyorsa ve az miktarda çıktı verisi veriyorsa

• Complex - sorgu yüksek işlem gerektiriyorsa ve büyük miktarda çıktı verisi veriyorsa

• Average - basit ve karmaşık arasında.

Sistemdeki bu parametrelerin her birine sınıflarına ve karmaşıklıklarına göre ağırlık verilir. Aşağıdaki tablo her bir parametreye verilen ağırlıktan bahseder:

Parametre	Basit	Ortalama	Karmaşık
Girişler	3	4	6
çıktılar	4	5	7
Soruşturma	3	4	6
Dosyalar	7	10	15
Arayüzler	5	7	10

Yukarıdaki tablo ham Fonksiyon Puanı verir. Bu işlev noktaları, ortamın karmaşıklığına göre ayarlanır. Sistem on dört farklı özellik kullanılarak tanımlanmıştır:

• Veri iletişimleri
• Dağıtılmış işlem
• Performans hedefleri
• İşlem yapılandırma yükü
• İşlem oranı
• Online veri girişi,
• Son kullanıcı verimliliği
• Çevrimiçi güncelleme
• Karmaşık işlem mantığı
• Re-usability
• Kurulum kolaylığı
• Operasyonel kolaylık
• Birden çok site
• Değişiklikleri kolaylaştırma arzusu

Bu özellik faktörleri daha sonra aşağıda belirtildiği gibi 0 ile 5 arasında derecelendirilir:

• Etkisi yok
• Incidental
• Moderate
• Average
• Significant
• Essential

Tüm derecelendirmeler daha sonra N olarak toplanır. N'nin değeri 0 ila 70 arasındadır (14 tür özellik x 5 derecelendirme türü). Aşağıdaki formülleri kullanarak Karmaşıklık Ayar Faktörlerini (CAF) hesaplamak için kullanılır:

CAF = 0.65 + 0.01N

Sonra,

Delivered Function Points (FP)= CAF x Raw FP

Bu FP daha sonra aşağıdakiler gibi çeşitli ölçümlerde kullanılabilir:

Cost = $ / FP

Quality = Hatalar / FP

Productivity = FP / kişi-ay

Bu bölümde, yazılım uygulamasındaki programlama yöntemleri, dokümantasyon ve zorluklar hakkında çalışacağız.

Yapısal Programlama

Kodlama sürecinde kod satırları çoğalmaya devam eder, dolayısıyla yazılımın boyutu artar. Yavaş yavaş, programın akışını hatırlamak neredeyse imkansız hale gelir. Yazılımın ve onun temelindeki programların, dosyaların, prosedürlerin nasıl oluşturulduğunu unutursanız, programı paylaşmak, hata ayıklamak ve değiştirmek çok zor hale gelir. Bunun çözümü yapısal programlamadır. Geliştiriciyi, kodda basit sıçramalar kullanmak yerine alt yordamları ve döngüleri kullanmaya teşvik eder, böylece kodda netlik sağlar ve verimliliğini artırır.

Yapısal programlama, programın nasıl kodlanacağını belirtir. Yapısal programlama üç ana kavram kullanır:

• Top-down analysis- Her zaman bazı rasyonel işleri gerçekleştirmek için bir yazılım yapılır. Bu rasyonel çalışma, yazılım sözlüğünde sorun olarak bilinir. Bu nedenle, sorunun nasıl çözüleceğini anlamamız çok önemlidir. Yukarıdan aşağıya analiz altında, sorun, her birinin bir önemi olan küçük parçalara bölünür. Her sorun ayrı ayrı çözülür ve sorunun nasıl çözüleceğine ilişkin adımlar açıkça belirtilir.

• Modular Programming- Programlama sırasında, kod daha küçük talimat grubuna bölünür. Bu gruplar modüller, alt programlar veya alt programlar olarak bilinir. Yukarıdan aşağıya analiz anlayışına dayalı modüler programlama. Programdaki 'goto' ifadelerini kullanarak atlamaları caydırır, bu da genellikle program akışını izlenemez hale getirir. Yapılandırılmış programlamada atlamalar yasaktır ve modüler format teşvik edilir.

• Structured Coding - Yukarıdan aşağıya analize referans olarak, yapılandırılmış kodlama, modülleri yürütme sırasına göre daha küçük kod birimlerine alt bölümlere ayırır. Yapılandırılmış programlama, programın akışını kontrol eden kontrol yapısını kullanırken, yapılandırılmış kodlama, talimatlarını tanımlanabilir modellerde düzenlemek için kontrol yapısını kullanır.

Fonksiyonel Programlama

Fonksiyonel programlama, matematiksel fonksiyonların kavramlarını kullanan programlama dili stilidir. Matematikteki bir fonksiyon, aynı argümanı aldığında her zaman aynı sonucu vermelidir. Prosedürel dillerde, programın akışı prosedürlerden geçer, yani programın kontrolü çağrılan prosedüre aktarılır. Kontrol akışı bir prosedürden diğerine aktarılırken, program durumunu değiştirir.

Prosedürel programlamada, bir prosedürün aynı argümanla çağrıldığında farklı sonuçlar üretmesi mümkündür, çünkü program onu ​​çağırırken farklı durumda olabilir. Bu, prosedür uygulamasının sırasının veya zamanlamasının önemli hale geldiği prosedürel programlamanın bir özelliği ve dezavantajıdır.

Fonksiyonel programlama, matematiksel fonksiyonlar olarak hesaplama araçları sağlar ve bu, program durumundan bağımsız olarak sonuçlar üretir. Bu, programın davranışını tahmin etmeyi mümkün kılar.

Fonksiyonel programlama aşağıdaki kavramları kullanır:

• First class and High-order functions - Bu işlevler, başka bir işlevi bağımsız değişken olarak kabul edebilir veya diğer işlevleri sonuç olarak döndürür.

• Pure functions - Bu işlevler, yıkıcı güncellemeleri içermez, yani herhangi bir G / Ç veya belleği etkilemezler ve kullanımda değillerse, programın geri kalanını engellemeden kolayca kaldırılabilirler.

• Recursion- Özyineleme, bir fonksiyonun kendisini çağırdığı ve önceden tanımlanmış bazı koşullar eşleşmediği sürece içindeki program kodunu tekrarladığı bir programlama tekniğidir. Özyineleme, fonksiyonel programlamada döngüler yaratmanın yoludur.

• Strict evaluation- Bir işleve argüman olarak iletilen ifadeyi değerlendirme yöntemidir. İşlevsel programlamanın iki tür değerlendirme yöntemi vardır: katı (istekli) veya katı olmayan (tembel). Katı değerlendirme, her zaman işlevi çağırmadan önce ifadeyi değerlendirir. Kesin olmayan değerlendirme, gerekmedikçe ifadeyi değerlendirmez.

• λ-calculus- İşlevsel programlama dillerinin çoğu, tür sistemleri olarak λ-kalkülüs kullanır. λ ifadeleri, oluştukları anda değerlendirilerek yürütülür.

Common Lisp, Scala, Haskell, Erlang ve F #, işlevsel programlama dillerinin bazı örnekleridir.

Programlama stili

Programlama stili, kod yazmak için tüm programcılar tarafından izlenen kodlama kuralları kümesidir. Birden çok programcı aynı yazılım projesi üzerinde çalışırken, sık sık başka bir geliştirici tarafından yazılan program koduyla çalışmaları gerekir. Tüm geliştiriciler programı kodlamak için bazı standart programlama stillerini takip etmezlerse, bu sıkıcı hale gelir veya bazen imkansız hale gelir.

Uygun bir programlama stili, amaçlanan görevle ilgili işlev ve değişken adlarının kullanılmasını, iyi yerleştirilmiş girintilerin kullanılmasını, okuyucunun rahatlığı için kodun yorumlanmasını ve kodun genel sunumunu içerir. Bu, program kodunu herkes tarafından okunabilir ve anlaşılabilir kılar, bu da hata ayıklamayı ve hata çözmeyi kolaylaştırır. Ayrıca, uygun kodlama stili dokümantasyon ve güncellemeyi kolaylaştırmaya yardımcı olur.

Kodlama Yönergeleri

Kodlama stilinin uygulanması organizasyonlara, işletim sistemlerine ve kodlama dilinin kendisine göre değişir.

Aşağıdaki kodlama öğeleri, bir kuruluşun kodlama yönergeleri altında tanımlanabilir:

• Naming conventions - Bu bölüm fonksiyonların, değişkenlerin, sabitlerin ve global değişkenlerin nasıl isimlendirileceğini tanımlar.

• Indenting - Bu, satırın başında kalan boşluktur, genellikle 2-8 boşluk veya tek sekme.

• Whitespace - Genellikle satırın sonunda ihmal edilir.

• Operators- Matematik, atama ve mantıksal operatörler yazmanın kurallarını tanımlar. Örneğin, "=" atama operatörü, "x = 2" gibi, öncesinde ve sonrasında boşluk içermelidir.

• Control Structures - If-then-else, case-switch, while-until ve yalnızca ve iç içe geçmiş şekilde kontrol akışı ifadeleri yazma kuralları.

• Line length and wrapping- Bir satırda kaç karakter olması gerektiğini tanımlar, çoğunlukla bir satır 80 karakter uzunluğundadır. Kaydırma, bir satırın çok uzunsa nasıl kaydırılması gerektiğini tanımlar.

• Functions - Bu, işlevlerin parametreli ve parametreler olmadan nasıl bildirilmesi ve çağrılması gerektiğini tanımlar.

• Variables - Bu, farklı veri türlerinin değişkenlerinin nasıl bildirildiğinden ve tanımlandığından bahseder.

• Comments- Kodda yer alan yorumlar, kodun gerçekte ne yaptığını ve diğer tüm ilişkili açıklamaları açıkladığından, bu önemli kodlama bileşenlerinden biridir. Bu bölüm ayrıca diğer geliştiriciler için yardım belgeleri oluşturmaya yardımcı olur.

Yazılım Dokümantasyonu

Yazılım dokümantasyonu, yazılım sürecinin önemli bir parçasıdır. İyi yazılmış bir belge, yazılım süreci hakkında bilgi sahibi olmak için gerekli olan harika bir araç ve bilgi havuzu aracı sağlar. Yazılım belgeleri ayrıca ürünün nasıl kullanılacağı hakkında bilgi sağlar.

İyi korunmuş bir belge aşağıdaki belgeleri içermelidir:

• Requirement documentation - Bu dokümantasyon, yazılım tasarımcısı, geliştirici ve test ekibinin ilgili görevlerini yerine getirmesi için anahtar araç olarak çalışır. Bu belge, amaçlanan yazılımın tüm işlevsel, işlevsel olmayan ve davranışsal tanımlarını içerir.

  Bu belgenin kaynağı, müşterinin tarafında zaten çalışan yazılım, müşteri görüşmesi, anketler ve araştırmalar hakkında önceden depolanmış veriler olabilir. Genellikle, üst düzey yazılım yönetim ekibi ile elektronik tablo veya kelime işlem belgesi biçiminde saklanır.

  Bu dokümantasyon, geliştirilecek yazılımın temeli olarak çalışır ve büyük ölçüde doğrulama ve onaylama aşamalarında kullanılır. Çoğu test senaryosu, doğrudan gereksinim belgelerinden oluşturulur.

• Software Design documentation - Bu belgeler, yazılımı oluşturmak için gereken tüm gerekli bilgileri içerir. Bu içerir:(a) Üst düzey yazılım mimarisi, (b) Yazılım tasarım detayları, (c) Veri akış diyagramları, (d) Veri tabanı tasarımı

  Bu belgeler, geliştiricilerin yazılımı uygulaması için depo görevi görür. Bu belgeler, programın nasıl kodlanacağına dair herhangi bir ayrıntı vermese de, kodlama ve uygulama için gerekli tüm gerekli bilgileri verir.

• Technical documentation- Bu belgeler geliştiriciler ve gerçek kodlayıcılar tarafından tutulur. Bu belgeler bir bütün olarak kodla ilgili bilgileri temsil eder. Programcılar kodu yazarken, kodun amacını, kimin yazdığını, nerede gerekli olacağını, ne yaptığını ve nasıl yaptığını, kodun başka hangi kaynakları kullandığını vb.

  Teknik dokümantasyon, aynı kod üzerinde çalışan çeşitli programcılar arasındaki anlayışı artırır. Kodun yeniden kullanım kabiliyetini artırır. Hata ayıklamayı kolay ve izlenebilir hale getirir.

  Çeşitli otomatik araçlar mevcuttur ve bazıları programlama dilinin kendisiyle birlikte gelir. Örneğin java, kodun teknik dokümantasyonunu oluşturmak için JavaDoc aracıyla birlikte gelir.

• User documentation- Bu belge, yukarıda açıklananların tümünden farklıdır. Yazılım ve geliştirme süreci hakkında bilgi sağlamak için önceki tüm belgeler saklanır. Ancak kullanıcı belgeleri, yazılım ürününün nasıl çalışması gerektiğini ve istenen sonuçları elde etmek için nasıl kullanılması gerektiğini açıklar.

  Bu belgeler, yazılım yükleme prosedürlerini, nasıl yapılır kılavuzlarını, kullanıcı kılavuzlarını, kaldırma yöntemini ve lisans güncellemesi gibi daha fazla bilgi almak için özel referansları içerebilir.

Yazılım Uygulama Zorlukları

Geliştirme ekibinin yazılımı uygularken karşılaştığı bazı zorluklar vardır. Bunlardan bazıları aşağıda belirtilmiştir:

• Code-reuse- Günümüz dillerinin programlama arayüzleri çok karmaşıktır ve büyük kütüphane işlevleriyle donatılmıştır. Yine de, son ürünün maliyetini düşürmek için organizasyon yönetimi, daha önce başka yazılımlar için oluşturulmuş olan kodu yeniden kullanmayı tercih ediyor. Uyumluluk kontrolleri ve ne kadar kodun yeniden kullanılacağına karar verme konusunda programcıların karşılaştığı büyük sorunlar var.

• Version Management- Müşteriye her yeni yazılım verildiğinde, geliştiricilerin sürüm ve konfigürasyonla ilgili belgeleri muhafaza etmesi gerekir. Bu belgelerin son derece doğru ve zamanında hazır olması gerekir.

• Target-Host- Organizasyonda geliştirilmekte olan yazılım programının müşteri tarafında ana makineler için tasarlanması gerekmektedir. Ancak bazen hedef makinelerde çalışan bir yazılım tasarlamak imkansızdır.

Yazılım Testi, yazılımın kullanıcılardan toplanan gereksinimlere ve sistem özelliklerine göre değerlendirilmesidir. Test, yazılım geliştirme yaşam döngüsünde faz düzeyinde veya program kodunda modül düzeyinde gerçekleştirilir. Yazılım testi, Doğrulama ve Doğrulamadan oluşur.

Yazılım Doğrulaması

Doğrulama, yazılımın kullanıcı gereksinimlerini karşılayıp karşılamadığını inceleme sürecidir. SDLC'nin sonunda gerçekleştirilir. Yazılım, yapıldığı gereksinimlere uyuyorsa, doğrulanır.

• Doğrulama, geliştirilmekte olan ürünün kullanıcı gereksinimlerine göre olmasını sağlar.
• Doğrulama şu soruyu yanıtlar - "Bu yazılımdan tüm bu kullanıcının ihtiyaçlarını karşılayan ürünü geliştiriyor muyuz?".
• Doğrulama, kullanıcı gereksinimlerini vurgular.

Yazılım Doğrulaması

Doğrulama, yazılımın iş gereksinimlerini karşılayıp karşılamadığını onaylama sürecidir ve uygun şartnamelere ve metodolojilere bağlı kalarak geliştirilir.

• Doğrulama, geliştirilmekte olan ürünün tasarım özelliklerine uygun olmasını sağlar.
• Doğrulama şu soruyu yanıtlıyor: "Bu ürünü tüm tasarım özelliklerini sıkı bir şekilde takip ederek mi geliştiriyoruz?"
• Doğrulamalar tasarım ve sistem özelliklerine odaklanır.

Testin hedefi -

• Errors- Bunlar geliştiriciler tarafından yapılan gerçek kodlama hatalarıdır. Ayrıca yazılımın çıktısında farklılık olması ve istenilen çıktıda hata olarak değerlendirilmektedir.

• Fault- Hata oluştuğunda hata oluşur. Hata olarak da bilinen bir hata, sistemin başarısız olmasına neden olabilecek bir hatanın sonucudur.

• Failure - Başarısızlığın, sistemin istenen görevi yerine getirememesi olduğu söylenir. Arıza, sistemde arıza olduğunda ortaya çıkar.

Manuel ve Otomatikleştirilmiş Test

Test, manuel olarak veya otomatik bir test aracı kullanılarak yapılabilir:

• Manual- Bu test, otomatik test araçlarının yardımı olmadan gerçekleştirilir. Yazılım test cihazı, kodun farklı bölümleri ve seviyeleri için test senaryoları hazırlar, testleri yürütür ve sonucu yöneticiye bildirir.

  Manuel test, zaman ve kaynak tüketir. Test uzmanının doğru test senaryolarının kullanılıp kullanılmadığını onaylaması gerekir. Testin büyük bir kısmı manuel testi içerir.

• AutomatedBu test, otomatik test araçlarının yardımıyla yapılan bir test prosedürüdür. Manuel test ile ilgili sınırlamalar, otomatik test araçları kullanılarak aşılabilir.

Bir web sayfasının Internet Explorer'da açılıp açılamayacağını kontrol etmesi gerekir. Bu, manuel test ile kolayca yapılabilir. Ancak web sunucusunun 1 milyon kullanıcının yükünü kaldırıp kaldırmadığını kontrol etmek için manuel olarak test etmek oldukça imkansızdır.

Test uzmanının yük testi, stres testi, regresyon testi yapmasına yardımcı olan yazılım ve donanım araçları vardır.

Test Yaklaşımları

Testler iki yaklaşıma göre yürütülebilir -

• İşlevsellik testi
• Uygulama testi

İşlevsellik, söz konusu gerçek uygulama dikkate alınmadan test edildiğinde, kara kutu testi olarak bilinir. Diğer taraf, yalnızca işlevselliğin test edildiği değil, aynı zamanda uygulanma biçiminin de analiz edildiği beyaz kutu testi olarak bilinir.

Kapsamlı testler, mükemmel bir test için istenen en iyi yöntemdir. Giriş ve çıkış değerleri aralığındaki her bir olası değer test edilir. Değer aralığı büyükse gerçek dünya senaryosunda her bir değeri test etmek mümkün değildir.

Kara kutu testi

Programın işlevselliğini test etmek için yapılır. Aynı zamanda 'Davranışsal' test olarak da adlandırılır. Bu durumda test cihazı, bir dizi giriş değerine ve ilgili istenen sonuçlara sahiptir. Girdi sağlandığında, çıktı istenen sonuçlarla eşleşirse, program 'tamam' olarak test edilir, aksi halde sorunludur.

Bu test yönteminde kodun tasarımı ve yapısı test uzmanı tarafından bilinmez ve test mühendisleri ve son kullanıcılar bu testi yazılım üzerinde gerçekleştirir.

Kara kutu test teknikleri:

• Equivalence class- Girdi benzer sınıflara ayrılmıştır. Bir sınıfın bir öğesi testi geçerse, tüm sınıfın geçtiği varsayılır.

• Boundary values- Giriş, yüksek ve düşük son değerlere bölünmüştür. Bu değerler testi geçerse, aradaki tüm değerlerin de geçebileceği varsayılır.

• Cause-effect graphing- Önceki her iki yöntemde de, bir seferde yalnızca bir giriş değeri test edilir. Neden (girdi) - Etki (çıktı), girdi değerlerinin kombinasyonlarının sistematik bir şekilde test edildiği bir test tekniğidir.

• Pair-wise Testing- Yazılımın davranışı birden çok parametreye bağlıdır. İkili testte, birden çok parametre farklı değerleri için çift olarak test edilir.

• State-based testing- Sistem, giriş sağlandığında durumunu değiştirir. Bu sistemler durumlarına ve girdilerine göre test edilir.

Beyaz kutu testi

Kod verimliliğini veya yapısını iyileştirmek için programı ve uygulamasını test etmek için yapılır. Aynı zamanda 'Yapısal' test olarak da bilinir.

Bu test yönteminde, kodun tasarımı ve yapısı test eden tarafından bilinir. Kodun programcıları bu testi kod üzerinde gerçekleştirir.

Aşağıda bazı Beyaz kutu test teknikleri verilmiştir:

• Control-flow testing- Kontrol akışı testinin amacı, tüm ifadeleri ve şube koşullarını kapsayan test senaryoları oluşturmaktır. Şube koşullarının hem doğru hem de yanlış olduğu test edilir, böylece tüm ifadeler kapsanabilir.

• Data-flow testing- Bu test tekniği, programda yer alan tüm veri değişkenlerini kapsamayı vurgular. Değişkenlerin nerede bildirildiğini ve tanımlandığını ve nerede kullanıldığını veya değiştirildiğini test eder.

Test Seviyeleri

Testin kendisi çeşitli SDLC seviyelerinde tanımlanabilir. Test süreci, yazılım geliştirmeye paralel olarak çalışır. Bir sonraki aşamaya geçmeden önce, bir aşama test edilir, doğrulanır ve doğrulanır.

Yazılımda gizli bir hata veya sorun kalmadığından emin olmak için ayrı ayrı test yapılır. Yazılım çeşitli düzeylerde test edilmiştir -

Birim Testi

Kodlama sırasında programcı, hatasız olup olmadığını anlamak için o program birimi üzerinde bazı testler yapar. Test, beyaz kutu test yaklaşımı altında gerçekleştirilir. Birim testi, geliştiricilerin programın ayrı birimlerinin gereksinime göre çalıştığına ve hatasız olduğuna karar vermelerine yardımcı olur.

Entegrasyon Testi

Yazılım birimleri ayrı ayrı iyi çalışıyor olsa bile, bir araya getirildiğinde birimlerin de hatasız çalışıp çalışmayacağını bulma ihtiyacı vardır. Örneğin, bağımsız değişken aktarma ve veri güncelleme vb.

Sistem Testi

Yazılım, ürün olarak derlenir ve daha sonra bir bütün olarak test edilir. Bu, aşağıdaki testlerden biri veya daha fazlası kullanılarak gerçekleştirilebilir:

• Functionality testing - Yazılımın tüm işlevlerini ihtiyaca göre test eder.

• Performance testing- Bu test, yazılımın ne kadar verimli olduğunu kanıtlıyor. Yazılımın istenen görevi yapmak için harcadığı ortalama süreyi ve etkinliği test eder. Performans testi, yazılımın çeşitli ortam koşullarında yüksek kullanıcı ve veri yüküne maruz bırakıldığı yük testi ve stres testi yoluyla yapılır.

• Security & Portability - Bu testler, yazılımın çeşitli platformlarda çalışması amaçlandığında ve kişi sayısı tarafından erişildiğinde yapılır.

Kabul testleri

Yazılım müşteriye teslim edilmeye hazır olduğunda, kullanıcı etkileşimi ve yanıtı açısından test edildiği son test aşamasından geçmelidir. Bu önemlidir, çünkü yazılım tüm kullanıcı gereksinimlerini karşılasa bile ve kullanıcı görünüşünden veya çalışmasından hoşlanmasa bile reddedilebilir.

• Alpha testing- Geliştirici ekibi, sistemi çalışma ortamında kullanılıyormuş gibi kullanarak alfa testi gerçekleştirir. Kullanıcının yazılımdaki bazı eylemlere nasıl tepki vereceğini ve sistemin girdilere nasıl yanıt vermesi gerektiğini bulmaya çalışırlar.

• Beta testing- Yazılım dahili olarak test edildikten sonra sadece test amacıyla kendi üretim ortamlarında kullanmaları için kullanıcılara teslim edilir. Bu henüz teslim edilen ürün değil. Geliştiriciler, bu aşamadaki kullanıcıların, katılmak için atlanan küçük problemler getirmesini bekliyorlar.

Gerileme testi

Bir yazılım ürünü yeni kod, özellik veya işlevsellikle güncellendiğinde, eklenen kodun herhangi bir olumsuz etkisi olup olmadığını tespit etmek için kapsamlı bir şekilde test edilir. Bu, regresyon testi olarak bilinir.

Test Belgeleri

Test belgeleri farklı aşamalarda hazırlanır -

Testten Önce

Test, test senaryolarının oluşturulmasıyla başlar. Referans için aşağıdaki belgelere ihtiyaç vardır -

• SRS document - İşlevsel Gereksinimler belgesi

• Test Policy document - Bu, ürünü piyasaya sürmeden önce ne kadar test yapılması gerektiğini açıklar.

• Test Strategy document - Bu, test ekibi, sorumluluk matrisi ve test yöneticisi ve test mühendisinin hakları / sorumluluğunun ayrıntılı yönlerinden bahseder.

• Traceability Matrix document- Bu, gereksinim toplama süreciyle ilgili SDLC belgesidir. Yeni gereksinimler geldikçe bu matrise eklenirler. Bu matrisler, test uzmanlarının gereksinim kaynağını bilmelerine yardımcı olur. İleri ve geri izlenebilirler.

Test Edilirken

Test başlatılırken ve yapılırken aşağıdaki belgeler gerekli olabilir:

• Test Case document- Bu belge, yapılması gereken testlerin listesini içerir. Birim test planı, Entegrasyon test planı, Sistem test planı ve Kabul test planını içerir.

• Test description - Bu belge, tüm test senaryolarının ve bunların yürütülmesine yönelik prosedürlerin ayrıntılı bir açıklamasıdır.

• Test case report - Bu belge, testin bir sonucu olarak test senaryosu raporunu içerir.

• Test logs - Bu belge, her test senaryosu raporu için test günlüklerini içerir.

Testten Sonra

Aşağıdaki belgeler testten sonra oluşturulabilir:

• Test summary- Bu test özeti, tüm test raporlarının ve günlüklerinin toplu analizidir. Yazılımın başlatılmaya hazır olup olmadığını özetler ve sonuca varır. Yazılım, başlatılmaya hazırsa sürüm kontrol sistemi altında yayınlanır.

Test, Kalite Kontrol, Kalite Güvencesi ve Denetime Karşı

Yazılım testinin yazılım kalite güvencesi, yazılım kalite kontrolü ve yazılım denetiminden farklı olduğunu anlamamız gerekir.

• Software quality assurance- Tüm önlemlerin organizasyon standartlarına göre alındığından emin olunan yazılım geliştirme süreci izleme araçlarıdır. Bu izleme, uygun yazılım geliştirme yöntemlerinin izlendiğinden emin olmak için yapılır.

• Software quality control- Bu, yazılım ürününün kalitesini korumak için bir sistemdir. Kuruluşun iyi niyetini artıran, yazılım ürününün işlevsel ve işlevsel olmayan yönlerini içerebilir. Bu sistem, müşterinin ihtiyaçları için kaliteli ürün almasını ve ürünün 'kullanıma uygun' olarak onaylanmasını sağlar.

• Software audit- Bu, kuruluş tarafından yazılımı geliştirmek için kullanılan prosedürün bir incelemesidir. Geliştirme ekibinden bağımsız bir denetçi ekibi, SDLC'nin yazılım sürecini, prosedürünü, gereksinimlerini ve diğer yönlerini inceler. Yazılım denetiminin amacı, hem yazılımın hem de geliştirme sürecinin standartlara, kurallara ve düzenlemelere uygunluğunu kontrol etmektir.

Yazılım bakımı, günümüzde SDLC'nin yaygın olarak kabul gören bir parçasıdır. Yazılım ürününün tesliminden sonra yapılan tüm değişiklik ve güncellemeleri ifade eder. Değişikliklerin gerekli olmasının birkaç nedeni vardır, bunlardan bazıları aşağıda kısaca belirtilmiştir:

• Market Conditions - Vergilendirme gibi zamanla değişen politikalar ve muhasebenin nasıl sürdürüleceği gibi yeni getirilen kısıtlamalar değişiklik ihtiyacını tetikleyebilir.

• Client Requirements - Zamanla, müşteri yazılımda yeni özellikler veya işlevler isteyebilir.

• Host Modifications - Hedef ana bilgisayarın herhangi bir donanımı ve / veya platformu (işletim sistemi gibi) değişirse, uyarlanabilirliği korumak için yazılım değişiklikleri gerekir.

• Organization Changes - Müşteri tarafında organizasyon gücünün azalması, başka bir şirketin satın alınması, yeni bir işe girişme girişiminde bulunulması gibi herhangi bir iş düzeyinde değişiklik varsa, orijinal yazılımda değişiklik yapma ihtiyacı ortaya çıkabilir.

Bakım türleri

Bir yazılım ömrü boyunca bakım türü, doğasına göre değişebilir. Bazı kullanıcılar tarafından keşfedilen bazı hatalar gibi sadece rutin bir bakım görevi olabilir veya bakım boyutuna veya doğasına bağlı olarak başlı başına büyük bir olay olabilir. Aşağıda, özelliklerine göre bazı bakım türleri verilmiştir:

• Corrective Maintenance - Bu, kullanıcı tarafından keşfedilen veya kullanıcı hata raporları ile sonuçlanan sorunları düzeltmek veya düzeltmek için yapılan değişiklikleri ve güncellemeleri içerir.

• Adaptive Maintenance - Bu, yazılım ürününü güncel tutmak ve sürekli değişen teknoloji ve iş ortamına uygun hale getirmek için uygulanan değişiklikleri ve güncellemeleri içerir.

• Perfective Maintenance- Bu, yazılımın uzun süre kullanılabilir durumda kalması için yapılan değişiklikleri ve güncellemeleri içerir. Yazılımın iyileştirilmesi ve güvenilirliği ile performansını iyileştirmek için yeni özellikler, yeni kullanıcı gereksinimleri içerir.

• Preventive Maintenance- Bu, yazılımın gelecekteki sorunlarını önlemek için değişiklikleri ve güncellemeleri içerir. Şu anda önemli olmayan ancak ileride ciddi sorunlara yol açabilecek sorunlara katılmayı hedefler.

Bakım Maliyeti

Raporlar, bakım maliyetinin yüksek olduğunu gösteriyor. Yazılım bakımını tahmin etme üzerine yapılan bir araştırma, bakım maliyetinin tüm yazılım süreci döngüsünün maliyetinin% 67'si kadar yüksek olduğunu buldu.

Ortalama olarak, yazılım bakım maliyeti tüm SDLC aşamalarının% 50'sinden fazladır. Bakım maliyetinin yükselmesine neden olan çeşitli faktörler vardır, örneğin:

Bakım Maliyetini etkileyen gerçek dünya faktörleri

• Herhangi bir yazılımın standart yaşı 10 ila 15 yıla kadar kabul edilir.
• Daha az bellek ve depolama kapasitesi ile yavaş makinelerde çalışması amaçlanan eski yazılımlar, modern donanım üzerinde yeni gelen geliştirilmiş yazılımlara karşı kendilerini zor durumda tutamazlar.
• Teknoloji ilerledikçe, eski yazılımı korumak maliyetli hale gelir.
• Çoğu bakım mühendisi acemidir ve sorunu gidermek için deneme yanılma yöntemini kullanır.
• Genellikle, yapılan değişiklikler yazılımın orijinal yapısına kolayca zarar verebilir ve bu da sonraki değişiklikler için zorlaşır.
• Değişiklikler genellikle belgesiz olarak bırakılır ve bu da gelecekte daha fazla çatışmaya neden olabilir.

Bakım Maliyetini etkileyen yazılım sonu faktörler

• Yazılım Programının Yapısı
• Programlama dili
• Dış ortama bağımlılık
• Personel güvenilirliği ve kullanılabilirliği

Bakım Faaliyetleri

IEEE, sıralı bakım süreci etkinlikleri için bir çerçeve sağlar. Yinelemeli bir şekilde kullanılabilir ve özelleştirilmiş öğeler ve süreçlerin dahil edilebilmesi için genişletilebilir.

Bu faaliyetler, aşağıdaki aşamaların her biri ile el ele gider:

• Identification & Tracing- Modifikasyon veya bakım gerekliliğinin belirlenmesi ile ilgili faaliyetleri içerir. Kullanıcı tarafından üretilir veya sistem günlükler veya hata mesajları ile raporlayabilir. Burada bakım türü de sınıflandırılır.

• Analysis- Değişiklik, güvenlik ve güvenlik etkileri de dahil olmak üzere sistem üzerindeki etkisi açısından analiz edilir. Olası etki şiddetli ise alternatif çözüm aranır. Daha sonra, bir dizi gerekli değişiklik, gereksinim spesifikasyonlarında gerçekleştirilir. Değişiklik / bakım maliyeti analiz edilir ve tahmin sonuçlandırılır.

• Design- Değiştirilmesi veya değiştirilmesi gereken yeni modüller, önceki aşamada belirlenen gereksinim özelliklerine göre tasarlanır. Doğrulama ve doğrulama için test senaryoları oluşturulur.

• Implementation - Tasarım aşamasında oluşturulan yapılandırılmış tasarım yardımı ile yeni modüller kodlanır.Her programcının paralel olarak birim testi yapması beklenir.

• System Testing- Yeni oluşturulan modüller arasında entegrasyon testi yapılır. Yeni modüller ve sistem arasında entegrasyon testi de yapılır. Son olarak sistem, gerileyen test prosedürleri izlenerek bir bütün olarak test edilir.

• Acceptance Testing- Sistem dahili olarak test edildikten sonra kullanıcılar yardımıyla kabul açısından test edilir. Bu durumda, kullanıcı ele alındığı veya bir sonraki yinelemede ele almaları gereken bazı sorunları şikayet ederse.

• Delivery- Kabul testinden sonra, sistem ya küçük güncelleme paketi ya da sistemin yeni kurulumu ile tüm organizasyona dağıtılır. Son test, yazılım teslim edildikten sonra istemci tarafında gerçekleştirilir.

  Kullanım kılavuzunun basılı kopyasına ek olarak gerekirse eğitim olanağı sağlanır.

• Maintenance management- Konfigürasyon yönetimi, sistem bakımının önemli bir parçasıdır. Sürümleri, yarı sürümü veya yama yönetimini kontrol etmek için sürüm kontrol araçlarıyla desteklenir.

Yazılım Yeniden Mühendislik

Yazılımı, işlevselliğini etkilemeden mevcut pazarda tutmak için güncellememiz gerektiğinde, buna yazılım yeniden mühendisliği denir. Yazılım tasarımının değiştirildiği ve programların yeniden yazıldığı kapsamlı bir süreçtir.

Eski yazılımlar, piyasadaki en son teknolojiye ayak uydurmaya devam edemez. Donanımın modası geçmiş hale geldikçe, yazılımın güncellenmesi bir baş ağrısı haline gelir. Yazılım zamanla eskiyse bile işlevselliği yaşlanmaz.

Örneğin, başlangıçta Unix, assembly dilinde geliştirildi. C dili ortaya çıktığında, Unix C'de yeniden tasarlandı, çünkü assembly dilinde çalışmak zordu.

Bunun dışında bazen programcılar, yazılımın birkaç parçasının diğerlerinden daha fazla bakıma ve ayrıca yeniden mühendisliğe ihtiyaç duyduklarını fark ederler.

Yeniden Mühendislik Süreci

• Decideneyin yeniden tasarlanacağı. Yazılımın tamamı mı yoksa bir parçası mı?
• Perform Mevcut yazılımın özelliklerini elde etmek için Tersine Mühendislik.
• Restructure ProgramEğer istenirse. Örneğin, işleve yönelik programları nesneye yönelik programlara dönüştürmek.
• Re-structure data gereğince, gerektiği gibi.
• Apply Forward engineering yeniden tasarlanmış yazılım elde etmek için kavramlar.

Yazılım yeniden mühendisliğinde kullanılan birkaç önemli terim vardır

Tersine mühendislik

Mevcut sistemi iyice analiz ederek, anlayarak sistem spesifikasyonuna ulaşma sürecidir. Bu süreç ters SDLC modeli olarak görülebilir, yani daha düşük soyutlama seviyelerini analiz ederek daha yüksek soyutlama seviyesi elde etmeye çalışıyoruz.

Var olan bir sistem, hakkında hiçbir şey bilmediğimiz daha önce uygulanan tasarımdır. Tasarımcılar daha sonra koda bakarak tersine mühendislik yapar ve tasarımı elde etmeye çalışır. Ellerinde tasarımla, şartnameleri tamamlamaya çalışırlar. Böylece, koddan sistem belirtimine tersine gidiliyor.

Programın Yeniden Yapılandırılması

Mevcut yazılımın yeniden yapılandırılması ve yeniden yapılandırılması sürecidir. Her şey, aynı programlama dilinde veya bir programlama dilinden farklı bir programlama dilinde kaynak kodunu yeniden düzenlemekle ilgilidir. Yeniden yapılandırma, kaynak kodu yeniden yapılandırmasına ve veri yeniden yapılandırmasına veya her ikisine birden sahip olabilir.

Yeniden yapılandırma, yazılımın işlevselliğini etkilemez, ancak güvenilirliği ve sürdürülebilirliği artırır. Çok sık hatalara neden olan program bileşenleri değiştirilebilir veya yeniden yapılandırma ile güncellenebilir.

Yazılımın eski donanım platformuna olan güvenilirliği, yeniden yapılanma yoluyla ortadan kaldırılabilir.

İleri Mühendislik

İleri mühendislik, tersine mühendislik yoluyla indirgenmiş, eldeki şartnamelerden istenen yazılımın elde edilmesi sürecidir. Geçmişte zaten yapılmış bazı yazılım mühendisliği olduğunu varsayar.

İleri mühendislik, yalnızca bir farkla yazılım mühendisliği süreciyle aynıdır - her zaman tersine mühendislikten sonra gerçekleştirilir.

Bileşenin yeniden kullanılabilirliği

Bir bileşen, sistemde bağımsız bir görevi yürüten yazılım programı kodunun bir parçasıdır. Küçük bir modül veya alt sistem olabilir.

Misal

Web'de kullanılan oturum açma prosedürleri bileşenler olarak değerlendirilebilir, yazılımdaki yazdırma sistemi yazılımın bir bileşeni olarak görülebilir.

Bileşenler, yüksek işlevsellik uyumuna ve daha düşük bağlantı oranına sahiptir, yani bağımsız olarak çalışırlar ve diğer modüllere bağlı olmadan görevleri yerine getirebilirler.

OOP'de nesneler, endişelerine çok özel tasarlanmıştır ve diğer bazı yazılımlarda kullanılma şansı daha azdır.

Modüler programlamada, modüller, diğer birçok yazılım programında kullanılabilen belirli görevleri gerçekleştirmek için kodlanır.

Yazılım bileşeninin yeniden kullanımına dayanan ve Bileşen Tabanlı Yazılım Mühendisliği (CBSE) olarak bilinen yepyeni bir dikey var.

Yeniden kullanım çeşitli seviyelerde yapılabilir

• Application level - Tüm bir uygulamanın yeni yazılımın alt sistemi olarak kullanıldığı yer.

• Component level - Bir uygulamanın alt sisteminin kullanıldığı yerlerde.

• Modules level - İşlevsel modüllerin yeniden kullanıldığı yerler.

  Yazılım bileşenleri, farklı bileşenler arasında iletişim kurmak için kullanılabilen arayüzler sağlar.

Yeniden Kullanım Süreci

İki tür yöntem benimsenebilir: ya gereksinimleri aynı tutarak ve bileşenleri ayarlayarak ya da bileşenleri aynı tutarak ve gereksinimleri değiştirerek.

• Requirement Specification - Bir yazılım ürününün uyması gereken işlevsel ve işlevsel olmayan gereksinimler, mevcut sistem, kullanıcı girdisi veya her ikisi yardımıyla belirlenir.

• Design- Bu aynı zamanda, gereksinimlerin yazılım dili açısından tanımlandığı standart bir SDLC işlem adımıdır. Sistemin bir bütün olarak temel mimarisi ve alt sistemleri oluşturulur.

• Specify Components - Yazılım tasarımını inceleyerek, tasarımcılar tüm sistemi daha küçük bileşenlere veya alt sistemlere ayırır. Eksiksiz bir yazılım tasarımı, birlikte çalışan çok sayıda bileşenden oluşan bir koleksiyona dönüşür.

• Search Suitable Components - Yazılım bileşeni deposu, işlevsellik ve amaçlanan yazılım gereksinimleri temelinde eşleşen bileşeni aramak için tasarımcılar tarafından yönlendirilir.

• Incorporate Components - Eşleşen tüm bileşenler, eksiksiz bir yazılım olarak şekillendirmek için bir araya getirilmiştir.

CASE kısaltması Cbilgisayar Akimlikli Sçok sayıda yazılım Ebaş döndürücü. Çeşitli otomatikleştirilmiş yazılım araçları yardımıyla yazılım projelerinin geliştirilmesi ve bakımı anlamına gelir.

CASE Araçları

CASE araçları, SDLC etkinliklerini otomatikleştirmek için kullanılan yazılım uygulama programları kümesidir. CASE araçları, yazılım sistemi geliştirmek için yazılım proje yöneticileri, analistler ve mühendisler tarafından kullanılır.

Yazılım Geliştirme Yaşam Döngüsünün çeşitli aşamalarını basitleştirmek için Analiz araçları, Tasarım araçları, Proje yönetimi araçları, Veritabanı Yönetimi araçları, Dokümantasyon araçları gibi çok sayıda CASE aracı bulunmaktadır.

CASE araçlarının kullanılması, istenen sonucu üretmek için projenin gelişimini hızlandırır ve yazılım geliştirmede bir sonraki aşamaya geçmeden önce kusurların ortaya çıkarılmasına yardımcı olur.

CASE Araçlarının Bileşenleri

CASE araçları, belirli bir SDLC aşamasında kullanımlarına bağlı olarak genel olarak aşağıdaki bölümlere ayrılabilir:

• Central Repository- CASE araçları, ortak, entegre ve tutarlı bilgi kaynağı olarak hizmet edebilecek merkezi bir havuz gerektirir. Merkezi depo, ürün özelliklerinin, gereksinim belgelerinin, ilgili raporların ve diyagramların, yönetimle ilgili diğer yararlı bilgilerin depolandığı merkezi bir depolama yeridir. Merkezi depo aynı zamanda veri sözlüğü görevi de görür.

  

• Upper Case Tools - Üst CASE araçları, SDLC'nin planlama, analiz ve tasarım aşamalarında kullanılır.

• Lower Case Tools - Uygulama, test ve bakımda daha düşük CASE araçları kullanılır.

• Integrated Case Tools - Entegre CASE araçları Gereksinim toplamadan Test ve dokümantasyona kadar SDLC'nin tüm aşamalarında faydalıdır.

CASE araçları, benzer işlevselliğe, süreç etkinliklerine ve diğer araçlarla entegre olma yeteneğine sahiplerse bir arada gruplanabilir.

Vaka Araçlarının Kapsamı

CASE araçlarının kapsamı, SDLC boyunca devam eder.

Kasa Araçları Türleri

Şimdi kısaca çeşitli CASE araçlarından geçiyoruz

Diyagram araçları

Bu araçlar, çeşitli yazılım bileşenleri ve sistem yapısı arasındaki sistem bileşenlerini, verileri ve kontrol akışını grafik biçiminde temsil etmek için kullanılır. Örneğin, son teknoloji akış şemaları oluşturmak için Akış Şeması Oluşturucu aracı.

Süreç Modelleme Araçları

Süreç modelleme, yazılımı geliştirmek için kullanılan yazılım süreç modelini oluşturma yöntemidir. Süreç modelleme araçları, yöneticilerin bir süreç modeli seçmesine veya yazılım ürününün gereksinimine göre onu değiştirmesine yardımcı olur. Örneğin, EPF Composer

Proje Yönetim Araçları

Bu araçlar proje planlaması, maliyet ve iş gücü tahmini, proje programlaması ve kaynak planlaması için kullanılır. Yöneticiler, yazılım proje yönetiminde belirtilen her adımda proje uygulamasına kesinlikle uymalıdır. Proje yönetimi araçları, proje bilgilerinin organizasyon genelinde gerçek zamanlı olarak depolanmasına ve paylaşılmasına yardımcı olur. Örneğin, Creative Pro Office, Trac Project, Basecamp.

Dokümantasyon Araçları

Bir yazılım projesinde dokümantasyon, yazılım sürecinden önce başlar, SDLC'nin tüm aşamaları boyunca ve projenin tamamlanmasından sonra devam eder.

Dokümantasyon araçları, teknik kullanıcılar ve son kullanıcılar için dokümanlar oluşturur. Teknik kullanıcılar çoğunlukla geliştirme ekibinin kurum içi uzmanlarıdır ve sistem kılavuzuna, başvuru kılavuzuna, eğitim kılavuzuna, kurulum kılavuzlarına vb. Başvurur. Son kullanıcı belgeleri, kullanım kılavuzu gibi sistemin işleyişini ve nasıl yapıldığını açıklar. Örneğin, dokümantasyon için Doxygen, DrExplain, Adobe RoboHelp.

Analiz Araçları

Bu araçlar, gereksinimleri toplamaya yardımcı olur, diyagramlardaki tutarsızlıkları, yanlışlıkları, veri fazlalıklarını veya hatalı ihmalleri otomatik olarak kontrol eder. Örneğin, gereksinim analizi için Accept 360, Accompa, CaseComplete, toplam analiz için Visible Analyst.

Tasarım Araçları

Bu araçlar, yazılım tasarımcılarının, iyileştirme teknikleri kullanılarak daha küçük modüllerde daha da parçalanabilen yazılımın blok yapısını tasarlamasına yardımcı olur. Bu araçlar, her modülün ayrıntılarını ve modüller arasındaki ara bağlantıları sağlar. Örneğin, Animasyonlu Yazılım Tasarımı

Yapılandırma Yönetim Araçları

Tek bir sürüm altında bir yazılım örneği yayınlanır. Konfigürasyon Yönetimi araçları -

• Sürüm ve revizyon yönetimi
• Temel yapılandırma yönetimi
• Kontrol yönetimini değiştir

CASE araçları buna otomatik izleme, sürüm yönetimi ve sürüm yönetimi ile yardımcı olur. Örneğin, Fossil, Git, Accu REV.

Kontrol Araçlarını Değiştir

Bu araçlar, yapılandırma yönetimi araçlarının bir parçası olarak kabul edilir. Temelleri sabitlendikten sonra veya yazılım ilk kez piyasaya sürüldükten sonra yazılıma yapılan değişikliklerle ilgilenirler. CASE araçları; değişiklik izleme, dosya yönetimi, kod yönetimi ve daha fazlasını otomatikleştirir. Ayrıca kuruluşun değişim politikasının uygulanmasına da yardımcı olur.

Programlama Araçları

Bu araçlar, IDE (Entegre Geliştirme Ortamı), yerleşik modüller kitaplığı ve simülasyon araçları gibi programlama ortamlarından oluşur. Bu araçlar, yazılım ürünü oluşturmada kapsamlı yardım sağlar ve simülasyon ve test için özellikler içerir. Örneğin, Cscope C, Eclipse'de kod aramak için.

Prototip Oluşturma Araçları

Yazılım prototipi, amaçlanan yazılım ürününün simüle edilmiş sürümüdür. Prototip, ürünün ilk görünümünü ve hissini sağlar ve gerçek ürünün birkaç yönünü simüle eder.

CASE araçlarının prototipini oluşturma temelde grafik kitaplıklarla birlikte gelir. Donanımdan bağımsız kullanıcı arayüzleri ve tasarım oluşturabilirler. Bu araçlar, mevcut bilgilere dayanarak hızlı prototipler oluşturmamıza yardımcı olur. Ek olarak, yazılım prototipinin simülasyonunu sağlarlar. Örneğin, Serena prototip bestecisi, Mockup Builder.

Web Geliştirme Araçları

Bu araçlar, formlar, metin, komut dosyası, grafik vb. Gibi tüm bağlantılı öğelerle web sayfalarının tasarlanmasına yardımcı olur. Web araçları ayrıca neyin geliştirildiğinin ve tamamlandıktan sonra nasıl görüneceğinin canlı önizlemesini sağlar. Örneğin, Fontello, Adobe Edge Inspect, Foundation 3, Brackets.

Kalite Güvence Araçları

Bir yazılım organizasyonunda kalite güvencesi, organizasyon standartlarına göre kalitenin uygunluğunu sağlamak için yazılım ürününü geliştirmek için benimsenen mühendislik sürecini ve yöntemlerini izlemektir. QA araçları, konfigürasyon ve değişiklik kontrol araçlarından ve yazılım test araçlarından oluşur. Örneğin, SoapTest, AppsWatch, JMeter.

Bakım Araçları

Yazılım bakımı, teslim edildikten sonra yazılım ürününde yapılan değişiklikleri içerir. Otomatik günlük kaydı ve hata raporlama teknikleri, otomatik hata bileti oluşturma ve temel neden analizi, SDLC'nin bakım aşamasında yazılım organizasyonuna yardımcı olan birkaç CASE aracıdır. Örneğin, hata izleme için Bugzilla, HP Kalite Merkezi.