İşverenimi dinlemeli ve CASE araçlarını kullanmalı mıyım?

İşverenim (Geliştirici Değil), CASE araçlarının geliştirme sürecimizi ve dokümantasyonumuzu geliştirmemize yardımcı olacağını düşünüyor. Bundan emin değilim, yerel müşteriler için mobil bankacılık çözümleri üreten 5 geliştiriciden oluşan küçük bir ekibiz. CASE araçlarının satın alınması gerektiği için zaman ve para kaybı olacağını düşünüyorum ve onlara alışmadan önce biraz zamana ihtiyacımız olacak ve modelleme ve şeyler için verimli bir şekilde çalışacağız. Kod üretimi başka bir sorun, gerçekten CASE oluşturulan kod iyi geliştiriciler tarafından yazılan kod kadar iyi olmayacağını düşünüyorum.

Çevik ilkelere, tasarım kalıplarına bağlı kalırsak TDD kullanırsak ve kodumuzu temiz tutarsak düşünüyorum. iyi olmalıyız. Analiz ve Tasarım konusunda, beyaz tahtadaki basit UML diyagramlarının hile yapması gerektiğini düşünüyorum. Dokümantasyon iyi ve önemlidir, ancak mümkün olduğunca az yapılmalı ve Dokümanlara odaklanmamalı ve kodu unutmamalıyız. Ben böyle düşünüyorum.

Doğrumuyum? veya işverenimi dinlemeli ve uygun bir CASE Aracı için araştırma yapmaya başlamalıyım?

Durum karara analitik bir yaklaşım gerektiriyor. Sonuç olarak "CASE aracı işletmeye bir değer sağlıyor mu?" Yönetim genellikle geliştiricilerin bir metodoloji veya araç benimsemelerini isteyecektir, çünkü kuruluşun mevcut süreçlerine ve kültürüne ne kadar iyi uyduğuna bakılmaksızın, bu konuda iyi şeyler duymuşlardır.

Eğer işvereniniz sizden CASE araçlarına bakmanızı isterse, ChrisF'in belirttiği gibi, mecbur olmalısınız (bu programlama değil, bir işyeri sorunudur). Bir CASE aracının benimsenmesini etkileyecek bazı faktörler şunlardır:

• Hangi işlemleriniz için CASE araçları mevcut,
• Yeni araç (lar) ı benimsemek için kaç kişi-saatin gerekli olacağına dair bir tahmin,
• Yeni araçların benimsenmesiyle süreçler nasıl değişecek,
• veya Yeni araç (lar) ın benimsenmesinden ne tür olumlu (veya olumsuz) etki ölçülebilir

Bunu geliştirme ortamınızı ve süreçlerinizi yükseltme fırsatı olarak düşünün. Mevcut süreçleriniz kuruluşunuzun kültürü için mükemmel bir eşleşme olabilir, ancak uygun araştırmayı yapmak için işvereninize ve ekibinize borçlusunuz.

Evet, CASE araçlarını araştırmaya başlamalısınız.

1. Çünkü yardım etmeyeceklerini iddia etmek için kanıtlara ihtiyacınız var . Asla bilemezsiniz, yardım edeceklerini görebilirsiniz.
2. Çünkü işvereniniz size söyledi.

David Kaczynski'nin mükemmel cevabında ortaya koyduğu puanları tekrarlamayacağım çünkü tam olarak izlemeniz gereken adımlar.

Gerçekten Agile'dan kod üretimi ile CASE / MDA odaklı gelişmeye büyük bir paradigma kayması gibi görünüyor. Proje yönetimi açısından (bir CASE yaklaşımı, yinelemeler, kullanıcı hikayeleri, hızlı geri bildirim veya sürekli iyileştirme kavramlarıyla çelişmeyecektir), ancak kesinlikle "yazılım işçiliği" perspektifinden bakıldığında - kod üzerinde daha az kontrol anlamına gelir üretilemeyen, okunamayan, katı, test edilmesi zor, sürekli modelle senkronize edilmesi gereken kodlar vb.

Açıkladığınızdan, işvereninizin neye ihtiyacı olduğu kolayca anlaşılabilir:

• Bir geliştirici ekipten ayrılırsa bilgi kaybını önlemek için daha iyi belgeler.
• Daha hızlı bir geliştirme süreci.

Bir yazılım uzmanı olarak, CASE yaklaşımının bu beklentileri karşılayabilme konusundaki şüphelerinizi kesinlikle söyleyebilir (ve söylemelisiniz). İsterse, CASE araçlarına bakmaya başlamak da sizin görevinizdir. Sadece bunlardan birini denemek, sonuçların tatmin edici olacağı anlamına gelmez (özellikle daha hızlı geliştirme ihtiyacı ile hangi tür çatışmaların potansiyel olarak büyük kod oluşturma yükünü düşünüyorum) ve 2 / mevcut çevik bağlamı korurken CASE aracının bazı özelliklerinin (diyagramlar, belge oluşturma) kullanılacağı bir uzlaşma bulmak.

Çevik bir ortamdaki CASE araçları ve olası yararları / dezavantajları hakkında ilginç bir makale: http://www.agilemodeling.com/essays/simpleTools.htm

İşverenim (Geliştirici Değil), CASE araçlarının geliştirme sürecimizi ve dokümantasyonumuzu geliştirmemize yardımcı olacağını düşünüyor. "

İşvereniniz için danışman olarak görev yapacak olsaydım, onları bu tür şeylerden caydırma girişiminde bulunmam gerekirdi. Her şeyden önce, işe dahil olmayan kişilerin geliştiriciler için araçlar seçmesi büyük bir yönetim hatasıdır. Bu neredeyse hiç iyi gitmez. Seçimi yapan insanların güçlü bir teknik geçmişi olmadığı zaman en az iki kat daha kötüdür. Ve ittikleri araçlarla ilgili herhangi bir deneyimleri yoksa, bu muhtemelen tam bir çöküş olacaktır.

Bu tür şeylerin teknik olmayan yönetim tarafından önerilmesinin en olası nedeni, birinin onlara bir şeyler satmaya çalışmasıdır. Bu tür şeyler satan büyük şirketlerden biri, nadir havalarda kurşun zeplin gibi düşen gelirlere sahiptir. Başka bir şeye geçmemiş olan satış görevlileri (diğer adıyla yeniden satıcılar, danışmanlar) küstahça yeni markalar, müşteriler ... bulmaya çalışıyor. Bu şirketlerin mücadele etmelerinin temel nedenlerinden biri, artık bu tür araçlara fazla talep olmamasıdır. 'Bu tür araçlar' ile, 'kod yazmayı ortadan kaldırmaya' söz veren araçlar kastediyorum. Dile bağlı olarak kodda yanlış bir şey yok. Yazılı kod, bu araçların sunduğundan çok daha güçlü soyutlamalara sahiptir.

Bunun kalkınmayı yönetmenin bu kadar kötü bir yolu olmasının temel nedenlerinden biri, ekibinizin personeline çekebileceğiniz mevcut insan havuzunu ciddi şekilde azaltacağıdır. Birincisi, bu nadir araçları öğrenmeleri gerekiyor ve ikincisi, çoğu deneyimli geliştirici bu şeylerle çalışmak istemiyor. Genellikle bu tür araçların etrafındaki adım, gerçekten iyi geliştiricilere ihtiyacınız olmadığıdır, çünkü bu araçlar ağır kaldırma işlemlerinin çoğunu yapar. Bu tamamen yanlış. Tam tersi. Önemsiz olan her şeyi yaparlar ve genellikle önemsiz olmayan parçaları zorlaştırırlar. Ayrıca kod yazma ihtiyacını asla ortadan kaldırmazlar.

Özellikle CASE araçlarıyla, bu paketlere sahip üç farklı yerde çalıştım. Her birinde, böyle gitti:

1. Model, araçta özenle tasarlandı. Normalden çok daha uzun sürdü ve çabanın sonlarına kadar kullanılabilir çıktılar üretilmedi.
2. Modelin iş mantığı ile güçlendirilmesi gerekiyordu. Model yanlıştı ve geç proje aşamalarında manuel olarak ince ayar yapılması gerekiyordu çünkü çaba çok gecikti.
3. Modeli ve kodu yeniden senkronize etmek o kadar düşük maliyetli ki CASE aracı rafa alındı, bir daha asla kullanılmayacak.

Özetle, her durumda% 100 toplam başarısızlık ve para kaybıdır. Diğer organizasyonlarda CASE araçlarını kullanan diğer insanlarla konuştuğumda hikaye hep aynı. Tüm bu araçları kullanmadım ve bazı insanların bunları iyi kullanmış olması mümkündür, ancak onları kullanan çoğu takımın uzun zaman önce kullanmayı bıraktığından oldukça eminim.

CASE araçlarını araştırmak / uygulamaktan elde edeceğiniz avantajlardan biri, gelecekteki istihdam için daha pazarlanabilir bir beceri seti edinmiş olmanızdır. Endişelerinizin birçoğunun dikkate değer olduğunu düşünüyorum, ancak David Kaczynski'nin de işaret ettiği gibi, bu bir işveren / çalışan ilişkisi sorusu kadar bir programlama sorusu değil. CASE araçlarının bir diğer yararı da, öğrendikten sonra, şirketinizin daha karmaşık ve daha çeşitli projeleri üstlenebilecek durumda olmasıdır. İşvereninizin almak istediği bir sözleşmenin CASE araçlarının kullanımını tercih etmesi veya tercih etmesi çok iyi olabilir.

Sorunu ve çözümü karıştırıyorsunuz ve patronunuz az çok başarılı bir şekilde yardım etmeye çalışıyor. Patronunuza meydan okumak için organizasyondaki rolünüzün ne olduğunu net olarak bilmelisiniz. Eğer CEO ve CTO iseniz karar sizin ve CEO sadece belgelerin eksikliğinden hangi iş unsurlarının etkilendiğine işaret etmelidir. Daha sonra yükümlülüğünüz, bir CASE aracıyla veya ortaya çıkardığınız başka bir çözümle iş sorununu çözmek olacaktır.

CASE araçlarını kullanmanın özel önerisiyle ilgili olarak, ekibinizi ekstra iş ile aşırı yüklemeden hedefinize ulaşmak için doğru bir şekilde seçmeniz gerektiğini düşünüyorum. Belgeler geliştirmek istediğiniz şeyse, kodu grafik diyagramdan oluşturmak için değil, koddan diyagramlar oluşturabilen bir araçla yeterli olabilir. Böyle bir araca örnek Codelogic'tir . Birkaç yıl önce tasarımlarımızın temiz ve net olduğu ve anlaşılması oldukça kolay olduğundan emin oldum. Eğer para ifade başka bir endişe ise muhtemelen açık kaynak bakabilirsiniz (Ben burada yardımcı olamaz ama herhangi bir araştırmanın sonucu ile ilgilenen olurdu).

CASE araçlarına alternatif de yardımcı olabilir. Siklomatik veya diğer karmaşıklık önlemleri gibi şeyleri ölçmek, tasarımınızı iyi yapılandırılmış ve geliştiricilerin koda odaklanmış olmasını sağlar. Kodunuzdaki daha iyi yorumlar, Javacode benzeri, dokümantasyonun iyileştirilmesine de yardımcı olabilir.

Dürüst olmak gerekirse, CASE araçlarının patronunuzun bunu bilmesine yardımcı olmadığını düşünüyorsanız. Eğer iyi bir patron ise, fikrinize değer verecektir. Eleştirel analiz yapmadan söylediklerini yapan bir çalışanı hiç sevmedim. Fakat elbette, David'in önerdiği gibi, güçlü ve nesnel argümanlar üzerine herhangi bir tartışma yapılmalıdır.

İşvereninize işleri geriye aldığını fark ettirmeye çalışıyordum. Yazılım ekibi için yatırım için yer varsa, darboğazlarınızın veya kalite sorunlarınızın ne olduğunu belirlemelisiniz. EĞER Eğer dokümantasyon ve gelişim süreci alanlarda iyileştirme için en odası var çıkıyor, bu alanların iyileştirilmesi açısından büyük YG elde ettiği ne değişiklikler tanımlamalıdır. Bu CASE araçlarını kullanmaya başlıyor olabilir veya olmayabilir.

Patronuna Yardım Et, Kendine Yardım Et

Bu talebe tepki verebilir veya bu talebe göre hareket edebilirsiniz.

Tüm "Fuji Dağı" sorularını hatırlıyor musun? Gerçekten istediğiniz bir iş için röportajda olsaydınız, görüşmeciye sorunun ne kadar aptal olduğunu söylemezdiniz, ama soru sormaya ve çözme konusunda en iyi fikirlerinizi ifade etmeye devam edersiniz. Bazı kültürlerde, sizden gerçekten Fuji Dağı'nı taşımanızı isteyen bir patrona hayır demezdiniz, ama ikinizin de yüzünü kurtarmanın bir yolunu bulursunuz.

Soruyu Yeniden Çerçeveleme

Eğer soruyu benzer bir şeye yeniden yansıtırsanız,

"Yazılımla ilgili düşük üretkenlik görevlerinin çoğunu mümkün olduğunca otomatik hale getiren bir takım araçlar satın alabilir veya başka türlü edinebilir miyim?"

bu görev çok daha lezzetli olur. CASE'e açık bir izlenebilirlik seçeneği ve bir veya iki Çevik / açık kaynak / bulut tabanlı seçenek sunarak patronunuza (ve kendinize) yardımcı olun.

CASE Tekrar

90'larda, CASE araçları Rational'dan muhtemelen Requisite Pro, Rational Rose, Clear Case, Rational Robot (bir test koşucusu), Purify, Pure Colay ve Quantify ve diğer birçok aracı içeren bir takım araçlar şeklinde olabilir. birlikte entegre edildi. Bir MAD mağazası (Medikal, Aviyonik, Savunma) olsaydınız, bu pazarlardaki müşteriler tarafından sıklıkla ihtiyaç duyulan kapsamlı ve izlenebilir belgeler ve eserler üretmek için bu araçların güncellenmiş sürümlerini kullanabilirsiniz.

IBM ile iletişim kurun ve beş lisans (veya yalnızca bir yüzen lisans) için teklif vermek üzere bir satıcıya başvurun. Biraz eğitim de ekleyin. Bu alıntıyı yöneticinizle paylaşmak, CASE araçları hakkındaki konuşmayı sona erdirebilir. Ama beni yanlış anlamayın. Rational'i, baş bilim adamlarını ve ürünlerini seviyorum, ancak esas olarak üniversite sitesi lisansları ile onlara eriştim çünkü fiyatları çalıştığım şirketler için çok yüksekti. Onaylanırsanız, en azından deneyimlerime göre, haklarınızı iyi destek, kaliteli eğitim (genellikle büyük gıda ile en iyi tesiste) ile tedavi edeceklerdir.

Satılık Araçlar

Alet alışverişine gitmek için hala harika bir fırsatınız var. Çevik geliştiriciler de araçlara ihtiyaç duyar. Çevrimiçi hikaye kartları, kullanım örnekleri, kullanım senaryosu ve diğer UML diyagram türleri için dokümantasyon desteği veren bir paket satın alabilirsiniz. Atlassian, görev ve hata izleme için Jira, Çevik proje yönetimi olarak tanımladıkları için Green Hopper, bir intranet wiki için Confluence, çevrimiçi kod inceleme için Crucible ve sürekli entegrasyon sunucusu için Bamboo olduğunu düşünüyorum. Çevikseniz, bu ve diğer araç takımlarınız için hizmet lisansı olarak yazılımlar bulunmaktadır.

IDE entegrasyonu, 2012 yılı CASE'e eşdeğer olmanın bir başka yoludur. Bir Microsoft geliştirme evi iseniz, Visual Team Studio, Rational'in yarattığı şeyle benzer araçlara sahiptir. Bazı gidiş-dönüş yazılım mühendisliği, sınıflardan birim test saplamaları oluşturma, kaynak kontrol sistemleriyle entegrasyon ve takım işbirliği için bir sürü araç var.

Açık Kaynak Araçları

Açık kaynak tarafında, Eclipse ve birçok eklentisi bir dizi açık kaynak aracını entegre etmeye çalışır. Eclipse Modeling Framework'ün olgun olup olmadığından ya da etkili gidiş-dönüş yazılım mühendisi veren başka araçlar olup olmadığından emin değilim, ancak son baktığımda başarmak çok kolay görünmüyordu. Qt Creator ortamı kaynak kontrolü ile bütünleşir ve editördeyken değişikliklerin kod kapsamından yerinde kontrol edilmesine yardımcı olacak bazı özelliklere sahiptir.

Yinelemeli Artımlı Aletin Benimsenmesi

Takım seçimine yinelemeli / artımlı bir yaklaşım da çok etkili olabilir. Açık kaynaklı projeler genellikle tekli veya çoklu ortamları destekler. Takım seçenekleriniz, kullandığınız yığınlardan etkilenebilir. Gelişimi tamamen kapatmak için asla iyi bir zaman yoktur, bu nedenle ekibi çeyrek başına birkaç küçük araçla eklemek ve eğitmek, her şeyi aynı anda değiştiren büyük bir patlama yaklaşımından daha iyi olabilir.

Bulut Aracı Çözümleri

Listelenen çözümlerin çoğu sunucular ve nispeten karmaşık kurulum gerektirebilir. Piyasaya, bulut tabanlı ve aylık bir ücret karşılığında bir sağlayıcı tarafından barındırılan bir hizmet olarak yazılım sağlayan birçok seçenek var. Bu, ekibiniz için kısa veya uzun vadede anlamlı olabilir. Bazılarında, daha sonra lisans satın alma seçeneğiyle hızlı bir başlangıç ​​için kullanabileceğiniz barındırılan bir çözüm olabilir.

Bu önerilerin hiçbiri, verimlilik artışı için ucuz ve kolay bir yol değildir, ancak bazı araçları denediğinizde vazgeçilmez bulabilirseniz.

Buradaki mükemmel cevaplara ekleyeceğim bir şey, "geliştirme sürecinizi nasıl iyileştirmek" istediğinizi anlamanızdan faydalanabilmenizdir.

Son 20 yıldaki ezici eğilim, piyasadaki zaman için yazılım geliştirmeyi optimize etmek oldu. "Çevik", "yalın", DevOps, TDD, BDD - hepsi mümkün olan en kısa sürede kaliteli yazılımları kapıdan çıkarmakla ilgilidir.

CASE araçları pazara sunma zamanı değildir. İzlenebilirlik, tasarım tutarlılığı, model bütünlüğü vb. Üzerine odaklanırlar. Bunların hepsi özellikle bankacılık sistemlerinde değerli yönlerdir, ancak piyasaya sürülmeleri pahasınadır.

Belki de patronunuza tam olarak neyi optimize etmeye çalıştığını sorun.

Deneyimden, CASE araçlarıyla çalışmak, özellikle ortalama olarak karmaşık olan sorunlu alanlarla çalışırken kodla çalışmaktan daha zor hale gelir. Proje, bir "bankacılık" projesi olmayı bırakmakta ve bunun yerine "CASE-aracını buraya ekle" projesi haline gelmektedir.