Her Şey Yazılım Geliştirmeye Yönelik Kapsamlı Kılavuzunuz

Bir fabrika üretim katı ve bir yazılım geliştirici ofisi ne kadar benzer?

Bilgisayarlarına kod yazan programcılarla dolu bir oda hayal edin. Ya çıktılarına fabrika montaj hattından birleştirilmiş aletler gibi davranırsanız? Üretimi maksimize eden şeyler burada da işe yarayacak mı? Yoksa geliştirme süreci daha çok diğer mühendislik disiplinlerine mi benziyor?

Proje yöneticileri, yazılım geliştirme başladığından beri bunu çözmeye çalışıyor. Bu sorulardan yazılım geliştirme yaşam döngüsünün tanımı ortaya çıkmıştır.

Yazılım geliştirme nedir?

Sıfırdan yazılım oluşturma sürecidir. Kod yazmak temel faaliyet olsa da, bundan çok daha fazlasıdır.

Geliştirme süreci, herhangi bir kod yazmadan önce fikir ve tasarım içerir. Planlamayı gözden kaçırmak kolaydır. Kod yazmanın yaptığı gibi geliştirme gibi hissetmiyor. Yine de önemli soruları yanıtlamak, önce bitmiş ürünü güçlendirir. Proje takip etmeye değer mi? Eğer öyleyse, bu konuda gitmenin en iyi yolu nedir? Hangi özellikler gerekli ve hangi özelliklere sahip olmak güzel? Cevaplar projeye daha iyi bir başarı şansı verir.

Adımlar sabit olmakla birlikte, uygulamaları değişir. Yazılım geliştirmenin nedeni yeni bir disiplindir. Mühendislik disiplinleri yüzlerce yıllık bir geçmişe sahiptir. Yazılım geliştirme sadece 1940'ların sonlarına kadar gider. Henüz yeni bir disiplin. Çevik yöntem sadece 20 yaşında. Yine de bu, yazılım oluşturma teorisinde meydana gelen en etkili şeylerden biridir. Ne olursa olsun, altı yazılım geliştirme yaşam döngüsü aşaması tüm sistemler için ortaktır.

Yazılım geliştirme yaşam döngüsünün (SDLC) 6 aşaması

Bir geliştirme ekibi, yazılım geliştirme yaşam döngüsünü bir projenin tamamında veya bir özellik üzerinde kullanabilir. SDLC kullanımının gelişimi, her adımın uzunluğunu kısaltarak riski azaltmakla ilgili olmuştur. Birazdan, farklı metodolojilere daha fazla bakacağız. İlk olarak, adımların kendilerini inceleyelim.

Ayrıca, adım sayısı veya adları açısından değişkenler göreceğinizi de belirtmekte fayda var. Bazen geliştirme ve test etme gibi adımlar birleştirilir. Diğer zamanlarda, planlamanın planlamaya ve analize dönüşmesi gibi ikiye bölünmüş bir adım görürsünüz. Bizim durumumuzda, aşamaları açıkça tanımladıkları için bu altı tanesine bağlı kalacağız.

1. Planlama

Planlama aşaması en önemli aşamadır. Paydaşlar, projenin fizibilitesi de dahil olmak üzere her şeyi düşünmelidir. Tüm projeyi burada öldürmek sorun değil. Sağlıklı bir organizasyon, paydaşları gerektiğinde bunu yapmaları için yetkilendirecektir. Programcıların bu aşamada kurumsal bir ortamda daha az katılımı olacaktır. Ürün sahipleri, iş analistleri ve diğer paydaşlar bu adımda ihtiyaçlarını dile getirirler.

2. Tasarım

Planlama aşaması en önemli aşamadır. Paydaşlar, projenin fizibilitesi de dahil olmak üzere her şeyi düşünmelidir. Tüm projeyi burada öldürmek sorun değil. Sağlıklı bir organizasyon, paydaşları gerektiğinde bunu yapmaları için yetkilendirecektir. Programcıların bu aşamada kurumsal bir ortamda daha az katılımı olacaktır. Ürün sahipleri, iş analistleri ve diğer paydaşlar bu adımda ihtiyaçlarını dile getirirler.

3. Geliştirme

Tasarım aşaması ayrıca kullanıcı deneyimi (UX) tasarımını da içerir. Uygulamanın kullanıcıya yönelik bileşenleri varsa, UX tasarımı bir zorunluluktur. Bu, gerçek kişilerin ürün maketleriyle etkileşimini izleyerek kullanıcı araştırmasını içerir. Bunun geliştirme aşaması yerine tasarım aşamasında gerçekleşmesinin nedeni zamanlamadır. Kullanıcı oturumları zaman alır. Genellikle iş paydaşlarıyla daha fazla ileri geri tartışma, toplanan verilerden de olur.

4. Test

Ardından, geliştirme ekibi kodu test eder. Kod yazan ve test eden kişi farklı kişiler olmalıdır. Daha da iyisi, geliştirici olmayan bir kalite güvence test cihazıdır. Geliştiriciler yalnızca mutlu yol senaryolarını düşünme eğilimindedir. Kendini işine adamış QA test uzmanları, yazılımı nasıl bozabileceklerini düşünmede daha iyi olma eğilimindedir. Bu şekilde dağıtımdan önce hata bulma olasılıkları daha yüksektir. Sonuç, piyasaya sürüldüğünde daha kararlı bir yazılımdır.

Otomatik ve manuel test

Birim testleri ve entegrasyon testleri genellikle otomatikleştirilir. Genellikle bir DevOps platformu, bu testleri ana dalla birleştirmeden önce yeni kod üzerinde çalıştırır.

Manuel test eskimiş olmaktan uzaktır. Otomatik testler aynı şeyi tekrar tekrar yapar. Yine de manuel test yapan bir kişi, test sırasında yanlışlıkla hataları bulabilir. Gücünü sağlayan şey, manuel testlerdeki değişkenliktir.

Birim testi

Birim testi, yalnızca bir yöntemi doğrular, başka bir şey değil. Test edilen fonksiyon sınırdır. Geliştirici birim testlerini yazar ve bazı SDLC çerçeveleri bunları zorunlu kılar. Aşırı Programlama bunları gerektirir. Aynı zamanda test odaklı geliştirmeyi de öngörür. Bu, önce birim testleri yazma uygulamasıdır. Ardından gerçek program kodunu yazma.

Entegrasyon testi

Entegrasyon testleri, kod tabanının bölümlerini veya özelliklerini kontrol eder. Genellikle otomatikleştirilirler ve DevOps platformu tarafından çalıştırılırlar. Doğruladıkları şey, tek bir yöntemden daha fazlasını kapsar. Bir örnek, bir API çağrısının bir veritabanında yeni bir kaydı sürdürdüğünü doğrulamaktır. Bunu, API yöntemini de doğrulayan bir birim testiyle karşılaştırın. Birim testi, yalnızca veritabanına bir çağrının gerçekleşmesi gerektiğini doğrulayabilir. Entegrasyon testi, verilerin uygulama üzerinden beklendiği gibi aktığını kanıtlayabilir.

Sistem testi

Testin son şekli tam sistem testidir. Özetlemek gerekirse, birim testi yalnızca bir işlevi doğrular. Entegrasyon testi bir özelliği doğrular. Ancak sistem testi, tüm uygulamayı tek bir birim olarak ele alır. Duman testi, sistem testinin hafif bir şeklidir. İçinde, test cihazı, sistemle doğal bir kullanıcının yapabileceği gibi etkileşime girer ve beklendiği gibi davranmasını sağlar. Daha titiz olan tam uçtan uca sistem testi ile karşılaştırılır. Tam sistem testi, bir sistemin tüm parçalarını tek bir varlık olarak kontrol eder. Ayrıca, bir dizi entegrasyon testi, tam bir sistem testi görevi görebilir.

5. Dağıtım

Dağıtım aşaması, test edilen kodu üretime zorluyor. Dağıtımı otomatikleştirmek onu daha güvenilir hale getirir. Ayrıca, üretim dağıtımlarını uygulamak, sorunsuz bir dağıtım olasılığını da artırır. Geliştirme ekibi, hazırlama ortamı adı verilen bir test ortamıyla çalışır. Üretim ile aynı olmalıdır. İki ortam birbirine ne kadar benzerse, uygulama dağıtımının değeri o kadar artar.

6. Bakım

SDLC'de bu noktaya kadar olan her şey, toplam sahip olma maliyetinin yalnızca dörtte biri kadar olacaktır. Yazılımın ilk geliştirme maliyeti , işletmenin harcayacağı miktarın %25'idir. Bakım aşaması, işletmeye toplam sahip olma maliyetinin yaklaşık %75'ine mal olacaktır. Balon bakım maliyetlerine karşı savunma, önceki aşamalara daha fazla dikkat edilir. Bu, daha iyi teknik tasarım, geliştirme ve daha kapsamlı testler anlamına gelir. Alternatif teknik borçtur. Gerçek borç gibi, zamanla daha pahalı hale gelir.

5 ana yazılım geliştirme metodolojisi

SDLC'nin adımları değişmezken, uygulama ve yürütme sıraları farklılık göstermektedir. Kuruluşların yazılım geliştirme sürecini gerçekleştirmelerinin en popüler yollarına bakalım.

1. Çevik

Agile'ı benzersiz kılan şey, insanlara odaklanmasıdır. Çevik metodolojiler, endüstrinin dikkatini yeniden odakladı. Önceleri ürüne, yazılıma odaklanıldı. Agile buna meydan okudu ve süreci yapan bireylere odaklandı. Ayrıca Agile Manifesto'dan önce Extreme Programming (XP) ve Scrum'ın hiçbir bağlantısı yoktu. Ancak daha sonra uygulayıcıları Çevik bayrak altında birleşti.

Çevik bir çerçeve değildir. Çerçeveler için bir çerçevedir. Özünde, insanlara ve hızlı yinelemelere odaklanmakla ilgilidir. Bu tam olarak adından da anlaşılacağı gibi, çevik. İyi yapıldığında sonuca ulaşmada esneklik vardır. Süreçler asla onlardan değer elde eden insanlar pahasına yapılmaz.

Agile'ın bir diğer önemli kiracısı yinelemeli bir yaklaşımdır. Buradaki fikir, iş bloklarını daha kısa sürede yapmaktır. Bu şekilde işletme, pazardaki değişikliklere daha hızlı uyum sağlayabilir. Gelişimin yönünü hızlı bir şekilde değiştirme yeteneği, onu çevik yapan şeydir. Aynı zamanda, geliştirme ekibi her yinelemede yaptıklarından bir şeyler öğrenebilir ve geliştirebilir. Çevik ekipler bunu her yinelemeden sonra geriye dönük toplantılarda yapar.

2. Aşırı programlama

Aşırı programlama (genellikle kısaltılmış XP) 1990'ların başında başladı. Martin Fowler, Çevik Manifesto'nun ilk imzacılarından biriydi. Agile'ın popülerliğini XP çerçevesi sayesinde kazandığını düşünüyor. Ayrıca, Çevik yazılım geliştirmeye başlamanın en iyi yolunun bu olduğunu savunuyor.

XP, adını yaklaşımından alır. Ortak iyi yazılım uygulamalarını alır ve gerektirir. Onu "aşırı" yapan da budur. XP, birim testleri, eşli programlama, daha sık yayınlama gibi şeyler gerektirir.

XP'yi benzersiz bir yöntem yapan şey:

• Kısa yineleme döngüleri (1 ila 2 hafta yaygındır)
• Geçerli yinelemede iş öğelerini değiştirmeye açıklık (Scrum'ın izin vermediği bir şey)
• Otomatik test ve çift programlamaya vurgu

3. Yalın

Yalın teknik olarak Çevik değildi, ancak pratikte buna benzer bir hissi var. Şimdi çoğu kişi tarafından Çevik'in bir parçası olarak kabul ediliyor. Odak noktası geleneksel Agile'dan farklıdır. Çevik manifestoya göre, "Bireyler ve süreçler ve araçlar üzerindeki etkileşimler." Yalın, üreticilerden çok yazılıma odaklanır.

Kökleri Toyota'nın Yalın üretim ilkeleridir. İşte onu tanımlayan yedi bölüm. Yalın üretime aşina iseniz, bunlar kulağa benzer gelecektir. Bunlar:

1. Atıkları ortadan kaldırın
2. Öğrenmeyi güçlendirin
3. Mümkün olduğunca geç karar verin
4. Mümkün olduğunca hızlı teslim edin
5. Ekibi güçlendirin
6. Bütünlük oluşturun
7. Bütünü optimize et

4. Scrum

Scrum, en popüler Agile yöntemidir. 14. Çevik Durum raporuna göre yazılım şirketlerinin %58'i Scrum kullanıyor. Scum melezlerini dahil ederseniz, yüzde %84'e fırlar. Hangisi soru soruyor, neden en popüler?

Cevap, Scrum'ın daha az zamanda daha fazla iş yapmakla ilgili olmasıdır. Bu işletmelere hitap ediyor. Scrum'daki her yineleme bir "sprint"tir. İsim hız fikrini pekiştiriyor. Genellikle, bir sprint 2 ila 3 hafta uzunluğundadır. Bir Scrum takımı bir sprint planladığında, hiç kimse onu değiştirmemelidir. Yeni iş, bir sonraki sprintin başlangıcına kadar beklemek zorundadır. Bu, iş paydaşları adına disiplin gerektirir. Pratikte bu Scrum kuralı sıklıkla ihlal edilir. Takımların sıklıkla bir Scrum hibriti yaptıklarını bildirmelerinin nedeni budur.

Scrum'ın bir diğer özelliği de Scrum Master'dır. Bu, sprint'i hedefte tutmaktan sorumlu olmak üzere aday gösterilen bir ekip üyesidir. Genellikle, Scrum Master, geliştirme ekibinden bir geliştiricidir.

Scrum'ın en yaygın çeşidi, Scrum ve Kanban'ın bir karışımı olan ScrumBan'dır. Kanban'ın kökleri, Yalın gibi Japon Toyota üretim sürecindedir. Tam zamanında çalışma sistemidir.

Her iş öğesi kendi başına bir yineleme gibidir. Bir geliştirici aynı anda yalnızca bir şey üzerinde çalışır. Kural, geliştirici başına bir "devam eden" öğedir. Bu katı devam eden çalışma sınırı, tüm darboğazlara ışık tutar. Geliştiriciler, bir Kanban panosu aracılığıyla devam eden iş öğelerini takip eder. Bir dip not olarak, isim buradan geliyor. Japonca'da Kanban, "tabela" anlamına gelir.

5. Şelale

Şelale yöntemi, tüm yazılım geliştirme uygulamalarının en eskisidir. Çevik'ten en az birkaç on yıl önce gelir. Bu yöntem de adından daha eskidir.

Şirketlerin her zaman yaptığı doğal yol budur. Bu doğrusal bir süreçtir ve en baştan başlarsınız. İlk olarak, paydaşlar gereksinimleri derler. Bunu bir iki özellik için yapmıyorlar. Hayır, iş paydaşları tüm projeyi bir kerede ele alır. Daha sonra çalışma başlar. Geliştiriciler, tamamlanana kadar tüm işleri yinelemeden yaparlar.

Şelale yolu, kavramsal olarak anlaşılması en kolay yoldur. İnsanlar her seferinde bir şey yapar. Bununla birlikte, iş başarısı için en riskli olanıdır. Bir şey hedef dışıysa, paydaşlar proje tamamlanana kadar düzeltemezler. Bunun nedeni, proje tamamlanana kadar fark edilmeyecek olmasıdır.

Yazılımın 3 temel alt türü

Bitmiş yazılım üç türden biridir. Bu türler sistem, programlama ve uygulama yazılımlarıdır. Örneklemek için, işte bir pasta pişirme benzetmesi. Bir mikser veya spatula, programlama yazılımıdır. Bu benzetmede daha fazla kek veya daha fazla yazılım uygulaması yapmanızı sağlar. Pasta montajı yapılırken en alt katman sistem yazılımıdır. Temel bu. Onsuz, katmanlı bir pastanız olamaz. En üst katman daha sonra uygulama yazılımı olacaktır. Çoğu sıradan gözlemcinin görebildiği şey budur.

Sistem yazılımı

Bir bilgisayarın işletim sistemi, sistem yazılımıdır. Kullanışlı olması çok önemli. İşletim sistemi olmayan bir bilgisayar düşünün. Onunla yalnızca makine dili aracılığıyla etkileşime girebilirsiniz. Bu saf ikili - sadece birler ve sıfırlar. Herhangi bir ölçekte çalışmayı imkansız bulursunuz. Sistem yazılımı, bir bilgisayarın kullanışlılığını açar.

Windows, macOS ve Linux, sistem yazılımının en popüler örnekleridir. Aygıt sürücüleri de sistem yazılımıdır. Bir işletim sisteminin temel işlevlerini genişletirler. İşletim sistemi olmayan akıllı cihazlar, işlevlerini etkinleştirmek için bellenim kullanır. Aynı zamanda sistem yazılımıdır.

programlama yazılımı

Programlama yazılımı, uygulama yazılımının bir alt kümesidir. Bir geliştiricinin yeni programlar oluşturmak için kullandığı herhangi bir program sınıflandıracaktır. Basit metin düzenleyicilerden karmaşık entegre geliştirme ortamlarına (IDE'ler) kadar çeşitlilik gösterirler. Çoğu geliştirici, daha karmaşık programlama yazılım araçlarını tercih eder. Microsoft'un Visual Studio gibi programlar geliştirmeyi hızlandırmaya yardımcı olur.

Uygulama yazılımı

Uygulama yazılımı en yaygın türdür. Bilgisayarla bir şeyler yapmanızı sağlayan yazılımdır. Bilgisayarları kullanışlı hale getirir. Popüler örnekler, Microsoft Word ve Excel gibi programlardır.

Bulut yazılımı da bu kategoriye girer. Google Dokümanlar, Dropbox ve hatta Instagram uygulama yazılımıdır. Bir şeyin uygulama yazılımı olup olmadığı konusunda kafanız karıştıysa, işte size basit bir test. Programın çalışması için başka bir şeye ihtiyacı var mı? Windows veya Android yok. Onlar sistem yazılımıdır. PowerPoint, hatta Call of Duty gibi bir oyun, çalışmak için çalışan başka şeylere ihtiyaç duyar, bu da onların uygulama yazılımı oldukları anlamına gelir. Aygıt sürücüleri ve bir işletim sistemi olmadan yürütülemezler.

Çözüm

Yazılım geliştirme yöntemleri hala olgunlaşmaktadır. Ancak kullanılan yöntem ne olursa olsun, adımlar aynı kalır. Çevik ekipler bunları daha hızlı yineleyebilir ve Şelale uygulayıcıları yavaş yavaş birinden diğerine geçer. Yine de daha iyi bir yazılım oluşturmak için her adım için süreci güçlendirmeniz gerekir. Birbirlerinin üzerine inşa ederler. Yazılım geliştirme yaşam döngüsü, adımlarından biri olmayan bir şey değildir. Parçalar bütünü oluşturur.

Herhangi bir adımdan vazgeçersen ne olacağını düşün. Ne yaptığınızı planlamadan? Tasarım olmadan geliştirme süreci gelişigüzel olacaktır. Geliştirme adımını dışarıda bırakmak imkansızdır. Test eksikliği, ürünün beklendiği gibi çalışmamasını sağlar. Dağıtım yoksa, hiç kimsenin ürünü kullanma erişimi olmayacaktır. Bakımsız bir uygulama kullanım dışı kalır. Her adım, bir yazılım ürününün başarısı için çok önemlidir.