İkinci sistem efektine karşı atmak için bir tane oluşturun

Bir yandan "Atmak için bir tane inşa et" yazan bir tavsiye vardır. Sadece bir yazılım sistemini bitirdikten ve son ürünü gördükten sonra tasarım aşamasında neyin yanlış gittiğinin farkındayız ve bunu gerçekten nasıl yapmamız gerektiğini anlıyoruz.

Öte yandan, tasarlanan aynı türden ikinci sistemin genellikle birincisinden daha kötü olduğunu söyleyen "ikinci sistem etkisi" vardır; ilk projeye uymayan ve genellikle aşırı karmaşık ve aşırı mühendislikle sonuçlanan ikinci versiyona itilmiş birçok özellik var.

Burada bu ilkeler arasında bir çelişki yok mu? Sorunlar hakkında doğru görüş nedir ve bu ikisi arasındaki sınır nerede?

Bu "iyi uygulamaların" ilk olarak Fred Brooks'un The Mythical Man-Month adlı efsanevi kitabında tanıtıldığına inanıyorum .

Bu sorunların bazılarının Agile metodolojileri tarafından çözüldüğünü biliyorum, ancak derinlemesine, sorun hala ayakta kalan ilkeler; örneğin canlı yayında 3 sprint önemli tasarım değişikliği yapmazdık.

Atmak için bir tane inşa etmek, başlangıçta "bilmediğinizi bilmemek" ten gelir, böylece başlangıçta ne yapmanız gerektiğini öğrenirsiniz.

İkinci Sistem Etkisi, "şimdi bilmediklerinizi bilmek, ancak hala bilmediğiniz şeyleri bilmemek" anlamına gelir. Yani İkinci sistem etkisi, bilgisiz ilkinden daha büyük, daha parlak, daha karmaşık bir sistem kurmaya çalışmaktan gelir. başlangıçta gerekli - ilk sistemde olanlara çok benziyor.

Dolayısıyla ikinci sistem etkisi çelişki değildir. Birinciyle aynı işlevselliğe sahip ikinci bir sistem kurmak (bildiklerime göre) asla yapılmaz. İkinci sistem her zaman "daha iyi" olmalıdır, bu nedenle daha karmaşıktır, bu nedenle ilk sistemle büyük ölçüde benzer sorunların ortaya çıkması beklenmektedir - bu atılmalıdır.

Öyleyse, atmak, onu atmak ve kapsam genişletme olmadan tekrar inşa etmek için bir tane oluşturun ve ikinci bir sistem probleminiz olmayacak. (Bu, mor gökyüzü, pembe denizler ve uçan domuzlara sahip gezegenlerde daha sık yapılır.)

Bahsettiğiniz sorun, birkaç şeyin atlandığı, dolayısıyla ortaya çıkan sistemin yanlış gittiği anlamına gelir. Bazı eksik adımları açıklayayım:

Kalite Yönetimi - İlk seferde doğru yapın! Asla geçici bir saldırı veya geçici uzlaşma kullanmayın. Yeniden işleme gerekmeyecektir. Tüm kaynaklar verimli bir şekilde kullanılıyor ve yaptığınız her şey projeye uygun bir katkı.

Fizibilite Analizi - İş gereksinimini keşfedin. Proje için bir iş vakası oluşturun.

Proje Planı - Başlangıç ​​kapsamınızı net bir şekilde tanımlayın, çözümün nasıl sunulacağını planlayın, bir temel oluşturun, plana sadık kalın. Kritik yolda olmayan hiçbir şeye zaman harcamayın.

Gereksinimler Mühendisliği - İş gereksinimlerini ortaya çıkarın (örn. İş süreçlerini yakalayın ve hangi iş işlemlerinin bilgisayarlı sistem tarafından desteklenmesi gerektiğini belirleyin, 1: 1 iş işlemlerini sistem kullanım durumlarına çevirin). Doğrula ve doğrula! (doğru olanı mı inşa ediyoruz? Doğru olanı mı inşa ediyoruz?) Tüm gereksinimler asıl iş ihtiyacına bağlı olmalıdır.

Yazılım Tasarımı - Kullanım örneklerini ve etki alanı modelini bileşen tasarımı ve çözüm mimarisine çevirin. Tüm bileşenler RE'nin gereksinimlerine bağlı olmalıdır.

Uygulama - Yazılımı tasarımdaki gibi kodlayın. Tüm kodlar SD bileşenlerine bağlanmalıdır.

Doğrulama - Birim testi, entegrasyon testi, performans, ... (RE'deki tüm kullanım durumlarının test edilmesi gerekecek)

Bunlar bir yazılım sürecinin bazı önemli yönleridir. Bahsedilen faaliyetler Yazılım Mühendisliği'nin bir parçasıdır. Gerçek iş ihtiyaçları için doğru yazılım çözümünü bu şekilde oluşturuyorsunuz ve bunu zamanında, bütçeye ve şartnameye göre oluşturuyorsunuz.

Daha iyi bir yazılım oluşturmak ve ilk seferde doğru yapmak için bu şartları inceleyin:

• Fizibilite Analizi (özellikle bir Ticari Durumun nasıl oluşturulacağı)
• Proje Yönetimi (özellikle Risk Azaltımı ile Proje Planı ve Risk Kaydı)
• Gereksinim Mühendisliği (eleme, analiz, şartname, validasyon)
• Yazılım Tasarımı (UML ve bileşen tabanlı yazılım mühendisliği)
• Yazılım Yapımı (tasarım modelleri, çerçeveler, savunma programlama)
• Yazılım Doğrulama (birim testi, UAT vb.)