CASE araçlarının değerlendirilmesi ve seçimi

1. Genel bilgiler

Aşağıda tartışılan değerlendirme ve seçim süreci modeli (Şekil 4.2), değerlendirme ve seçimin en genel durumunu tanımlar ve ayrıca bunlar arasındaki ilişkiyi gösterir. Görüldüğü gibi değerlendirme ve seçim birbirinden bağımsız ya da birlikte yapılabilmekte, bu süreçlerin her biri belirli kriterlerin uygulanmasını gerektirmektedir.

Değerlendirme ve seçim sürecinin, aşağıdakilerden biri veya daha fazlası dahil olmak üzere çeşitli hedefleri olabilir:

  • birkaç CASE aracının değerlendirilmesi ve bunlardan bir veya daha fazlasının seçilmesi;
  • bir veya daha fazla CASE aracının değerlendirilmesi ve sonuçların daha sonra kullanılmak üzere saklanması;
  • önceki değerlendirmelerin sonuçlarını kullanarak bir veya daha fazla CASE aracının seçilmesi.

Pirinç. 4.2. Değerlendirme ve seçim süreci modeli

Şekilden de görülebileceği gibi, değerlendirme süreci için girdi bilgileri şöyledir:

  • kullanıcı ihtiyaçlarının tanımlanması;
  • projenin hedefleri ve sınırlamaları;
  • mevcut CASE araçlarına ilişkin veriler;
  • değerlendirme sürecinde kullanılan kriterlerin bir listesi.

Değerlendirme sonuçları önceki değerlendirmelerin sonuçlarını içerebilir. Ancak bir önceki değerlendirmede kullanılan kriter setinin mevcut set ile uyumlu olması gerektiği unutulmamalıdır. özel seçenek sürecin uygulanması (değerlendirme ve seçim, gelecekteki seçim için değerlendirme veya önceki değerlendirmelere dayalı seçim) yukarıda sıralanan hedeflere göre belirlenir.

Süreç öğeleri şunları içerir:

  • süreç boyunca iyileştirilebilecek hedefler, varsayımlar ve kısıtlamalar;
  • CASE araçları için kullanıcıların nicel ve nitel gereksinimlerini yansıtan kullanıcı ihtiyaçları;
  • değerlendirmenin yapıldığı ve seçim kararının verildiği bir dizi parametreyi tanımlayan kriterler;
  • bir veya daha fazla aracın değerlendirilmesinin resmileştirilmiş sonuçları;
  • önerilen bir karar (genellikle bir seçim kararı veya ileri değerlendirme).

Değerlendirme ve/veya seçim süreci, yalnızca bir kişi, grup veya kuruluş kendisi için özel ihtiyaçları tam olarak tanımladığında ve bunları belirli bir konu alanında niceliksel ve niteliksel gereksinimler şeklinde resmileştirdiğinde başlatılabilir. Bundan sonra "kullanıcı gereksinimleri" terimi, sadece bu tür resmileştirilmiş gereksinimler anlamına gelir.

Kullanıcı, belirli eylem planını ve gerekli yinelemelerle karar vermeyi belirlemelidir. Örneğin, süreç, sıralı geçişi ve daha ayrıntılı değerlendirme için aday alt kümelerinin seçimi ile bir karar ağacı olarak temsil edilebilir. Eylem dizisinin açıklaması, aralarındaki veri akışını tanımlamalıdır.

Ölçüt listesi tanımı, kullanıcı gereksinimlerine dayalıdır ve şunları içerir:

  • aşağıdaki listeden kullanım kriterlerinin seçimi;
  • ek kriterlerin tanımı;
  • her bir kriterin kapsamının tanımlanması (değerlendirme, seçim veya her ikisi);
  • her bir değerlendirme kriteri için bir veya daha fazla metrik tanımlama;
  • her seçim kriterine bir ağırlık atama.

Değerlendirme süreci

Değerlendirme sürecinin amacı, sonraki seçim için CASE araçlarının işlevselliğini ve kalitesini belirlemektir. Değerlendirme, belirli kriterlere göre gerçekleştirilir ve sonuçları, her çare için hem nesnel hem de öznel verileri içerir.

Değerlendirme süreci aşağıdaki adımları içerir:

  • değerlendirmenin amacı ve kapsamı hakkında bilgiler de dahil olmak üzere, değerlendirmenin amacının beyanı;
  • görev tanımından kaynaklanan değerlendirme kriterlerinin tanımı;
  • aday listesini inceleyerek ve belirli fonlarla ilgili bilgileri analiz ederek aday fonların belirlenmesi;
  • aday fonların seçilen kriterler bağlamında değerlendirilmesi. Bunun için gerekli veriler, araçların kendilerini ve belgelerini analiz ederek, kullanıcılarla görüşerek, demo sürümleriyle çalışarak, test senaryolarını çalıştırarak, araçlarla deneyler yaparak ve önceki değerlendirmelerin sonuçlarını analiz ederek elde edilebilir;
  • değerlendirme sonuçlarına ilişkin bir raporun hazırlanması.

Değerlendirme sürecindeki en önemli kriterlerden biri, aday araçların her birinin halihazırda faaliyette olan veya organizasyonda kullanılması planlanan diğer araçlarla olası entegrasyonu olabilir.

Değerlendirmenin kapsamı, gereken ayrıntı düzeyini, gereken kaynakları ve sonuçların uygulanabilirliğini ortaya koymalıdır. Örneğin, değerlendirme bir veya daha fazla spesifik CASE tesisi üzerinde gerçekleştirilmelidir; Yazılım oluşturmak ve sürdürmek için bir veya daha fazla belirli süreci destekleyen CASE araçları veya bir veya daha fazla projeyi veya proje türünü destekleyen CASE araçları.

Otomatik olmayan (manuel) geliştirme ile pratik olarak imkansız olduğundan, bu metodolojinin yaygın kullanımı ve belirli IS'lerin geliştirilmesinde tavsiyelerine uyulması oldukça nadirdi. Gerçekten de, sistemin katı biçimsel özelliklerini manuel olarak geliştirmek ve grafiksel olarak sunmak, eksiksizlik ve tutarlılık açısından kontrol etmek ve hatta değiştirmek çok zordur. Bununla birlikte, katı bir tasarım belgeleri sistemi oluşturmak mümkünse, ciddi değişiklikler ortaya çıktığında işlenmesi pratik olarak imkansızdır.

CASE (Bilgisayar Destekli Yazılım Mühendisliği) terimi şu anda çok geniş bir anlamda kullanılmaktadır. Yalnızca yazılımın (yazılımın) geliştirilmesini otomatikleştirme sorunlarıyla sınırlı olan CASE teriminin orijinal anlamı artık edinilmiştir. yeni anlam genel olarak karmaşık IS geliştirme sürecini kapsar. Şimdi, CASE araçları terimi, gereksinimlerin analizi ve formülasyonu, uygulama yazılımı (uygulamalar) ve veritabanlarının tasarımı, kod üretimi, test etme, belgeleme, kalite güvencesi, konfigürasyon yönetimi dahil olmak üzere IS oluşturma ve sürdürme süreçlerini destekleyen yazılım araçlarını ifade eder. ve proje yönetimi ve diğer süreçlerin yanı sıra. CASE araçları, sistem yazılımı ve donanımıyla birlikte eksiksiz bir IS geliştirme ortamı oluşturur.

CASE teknolojisine yatırım yapma konusunda bilinçli bir karar vermek için kullanıcılar, eksik ve çelişkili verilere dayalı olarak bireysel CASE araçlarını değerlendirmek zorunda kalıyor. Bu sorun, genellikle CASE araçlarını kullanmanın tüm olası "tuzakları" hakkında yetersiz bilgi ile daha da kötüleşir. En önemli sorunlar arasında şunlar yer almaktadır:

  • CASE araçlarına yapılan yatırımın geri dönüşünün güvenilir bir şekilde değerlendirilmesi, projeler ve yazılım geliştirme süreçlerinde kabul edilebilir ölçütlerin ve verilerin bulunmaması nedeniyle zordur;
  • CASE araçlarının uygulanması yeterli olabilir uzun süreç ve anında getiri sağlamayabilir. Hatta uygulamada harcanan emek sonucunda verimlilikte kısa süreli düşüşler yaşanabilir. Sonuç olarak, kullanıcı kuruluşun yönetimi CASE araçlarına olan ilgisini kaybedebilir ve bunların uygulanmasını desteklemeyi bırakabilir;
  • CASE araçları tarafından desteklenen süreçler ve yöntemler ile bu organizasyonda kullanılanlar arasında tam bir uyum olmaması ek zorluklara yol açabilir;
  • CASE araçlarının diğer benzer araçlarla birlikte kullanılması genellikle zordur. Bunun nedeni, hem farklı araçlar tarafından desteklenen farklı paradigmalar hem de veri ve kontrolü bir araçtan diğerine aktarma sorunlarıdır;
  • bazı CASE araçları, uygulamalarının zorunlu kıldığı disiplinden yararlanmaya devam ederken, küçük bir projede kullanımlarını haklı çıkarmak için çok fazla çaba gerektirir;
  • olumsuz tutum Personelin yeni CASE teknolojisinin tanıtımı, projenin başarısızlığının ana nedeni olabilir.

CASE araçlarının kullanıcıları, uzun vadeli bakım maliyetleri ihtiyacına, yeni sürümlerin sık sık ortaya çıkmasına ve araçların olası hızlı eskimesine ve ayrıca sürekli eğitim ve personel geliştirme maliyetlerine hazırlıklı olmalıdır.

Aşağıda tartışılan değerlendirme ve seçim süreci modeli (Şekil 1), en genel değerlendirme ve seçim durumunu açıklar ve ayrıca bunlar arasındaki ilişkiyi gösterir. Görüldüğü gibi değerlendirme ve seçim birbirinden bağımsız ya da birlikte yapılabilmekte, bu süreçlerin her biri belirli kriterlerin uygulanmasını gerektirmektedir. Değerlendirme ve seçim sürecinin, aşağıdakilerden biri veya daha fazlası dahil olmak üzere çeşitli hedefleri olabilir:

  • birkaç CASE aracının değerlendirilmesi ve bunlardan bir veya daha fazlasının seçilmesi;
  • bir veya daha fazla CASE aracının değerlendirilmesi ve sonuçların daha sonra kullanılmak üzere saklanması;
  • önceki değerlendirmelerin sonuçlarını kullanarak bir veya daha fazla CASE aracının seçilmesi.

Pirinç. 1. Değerlendirme ve seçim sürecinin modeli

Şekilden de görülebileceği gibi, değerlendirme süreci için girdi bilgileri şöyledir:

  • kullanıcı ihtiyaçlarının tanımlanması;
  • projenin hedefleri ve sınırlamaları;
  • mevcut CASE araçlarına ilişkin veriler;
  • değerlendirme sürecinde kullanılan kriterlerin bir listesi.

Değerlendirme sonuçları önceki değerlendirmelerin sonuçlarını içerebilir. Ancak bir önceki değerlendirmede kullanılan kriter setinin mevcut set ile uyumlu olması gerektiği unutulmamalıdır. Sürecin özel uygulaması (değerlendirme ve seçim, gelecekteki seçim için değerlendirme veya önceki değerlendirmelere dayalı seçim) yukarıda sıralanan hedeflere göre belirlenir.

Süreç öğeleri şunları içerir:

  • süreç boyunca iyileştirilebilecek hedefler, varsayımlar ve kısıtlamalar;
  • CASE araçları için kullanıcıların nicel ve nitel gereksinimlerini yansıtan kullanıcı ihtiyaçları;
  • değerlendirmenin yapıldığı ve seçim kararının verildiği bir dizi parametreyi tanımlayan kriterler;
  • bir veya daha fazla aracın değerlendirilmesinin resmileştirilmiş sonuçları;
  • önerilen bir karar (genellikle bir seçim kararı veya ileri değerlendirme).

Değerlendirme ve/veya seçim süreci, yalnızca bir kişi, grup veya kuruluş kendisi için özel ihtiyaçları tam olarak tanımladığında ve bunları belirli bir konu alanında niceliksel ve niteliksel gereksinimler şeklinde resmileştirdiğinde başlatılabilir. Bundan sonra "kullanıcı gereksinimleri" terimi, sadece bu tür resmileştirilmiş gereksinimler anlamına gelir.

Kullanıcı, belirli eylem planını ve gerekli yinelemelerle karar vermeyi belirlemelidir. Örneğin, süreç, sıralı geçişi ve daha ayrıntılı değerlendirme için aday alt kümelerinin seçimi ile bir karar ağacı olarak temsil edilebilir. Eylem dizisinin açıklaması, aralarındaki veri akışını tanımlamalıdır.

Ölçüt listesi tanımı, kullanıcı gereksinimlerine dayalıdır ve şunları içerir:

  • aşağıdaki listeden kullanım kriterlerinin seçimi;
  • ek kriterlerin tanımı;
  • her bir kriterin kapsamının tanımlanması (değerlendirme, seçim veya her ikisi);
  • her bir değerlendirme kriteri için bir veya daha fazla metrik tanımlama;
  • her seçim kriterine bir ağırlık atama.

Değerlendirme sürecinin amacı, sonraki seçim için CASE araçlarının işlevselliğini ve kalitesini belirlemektir. Değerlendirme, belirli kriterlere göre gerçekleştirilir ve sonuçları, her çare için hem nesnel hem de öznel verileri içerir.

Değerlendirme süreci aşağıdaki adımları içerir:

  • değerlendirmenin amacı ve kapsamı hakkında bilgiler de dahil olmak üzere, değerlendirmenin amacının beyanı;
  • görev tanımından kaynaklanan değerlendirme kriterlerinin tanımı;
  • aday listesini inceleyerek ve belirli fonlarla ilgili bilgileri analiz ederek aday fonların belirlenmesi;
  • aday fonların seçilen kriterler bağlamında değerlendirilmesi. Bunun için gerekli veriler, araçların kendilerini ve belgelerini analiz ederek, kullanıcılarla görüşerek, demo sürümleriyle çalışarak, test senaryolarını çalıştırarak, araçlarla deneyler yaparak ve önceki değerlendirmelerin sonuçlarını analiz ederek elde edilebilir;
  • değerlendirme sonuçlarına ilişkin bir raporun hazırlanması.

Değerlendirme sürecindeki en önemli kriterlerden biri, aday araçların her birinin halihazırda faaliyette olan veya organizasyonda kullanılması planlanan diğer araçlarla olası entegrasyonu olabilir.

Değerlendirmenin kapsamı, gereken ayrıntı düzeyini, gereken kaynakları ve sonuçların uygulanabilirliğini ortaya koymalıdır. Örneğin, değerlendirme bir veya daha fazla spesifik CASE tesisi üzerinde gerçekleştirilmelidir; Yazılım oluşturmak ve sürdürmek için bir veya daha fazla belirli süreci destekleyen CASE araçları veya bir veya daha fazla projeyi veya proje türünü destekleyen CASE araçları.

CASE araçlarının listesi - olası adaylar çeşitli kaynaklardan oluşturulmuştur: yazılım pazarı incelemeleri, satıcı bilgileri, CASE araçları incelemeleri ve diğer benzer yayınlar.

Bir sonraki adım, CASE tesisleri hakkında bilgi almak veya bunları kendileri almak veya her ikisini birden yapmaktır. Bu bilgiler, bağımsız yargılardan, CASE aracı satıcılarından gelen iletişimlerden ve raporlardan, satıcılar tarafından CASE aracı gösterilerinden ve doğrudan gerçek kullanıcılardan alınan bilgilerden oluşabilir. CASE araçları satın alınarak, bir değerlendirme kopyası olarak veya başka yollarla elde edilebilir.

İlgili verilerin değerlendirilmesi ve toplanması gerçekleştirilebilir aşağıdaki şekillerde:

  • CASE araçlarının ve satıcı belgelerinin analizi;
  • gerçek kullanıcıların anketi;
  • bu CASE araçlarını kullanan projelerin sonuçlarının analizi;
  • gösterileri ve oy kullanan göstericileri izlemek;
  • test senaryolarının yürütülmesi;
  • CASE araçlarının pilot projelerde uygulanması;
  • Önceki değerlendirmelerden elde edilen mevcut sonuçların analizi.

Hem nesnel hem de öznel kriterler vardır. Belirli bir kritere göre değerlendirme sonuçları ikili olabilir, belirli bir sayısal aralıkta olabilir, basit bir sayısal değer olabilir veya başka bir biçimde olabilir.

Objektif kriterler için değerlendirme, tekrarlanabilir bir prosedürle yapılmalıdır, böylece değerlendirmeyi yapan herhangi bir kişi aynı sonuçları elde edebilir. Test senaryoları kullanılıyorsa, kümeleri önceden tanımlanmalı, birleştirilmeli ve belgelenmelidir.

Sübjektif kriterlere göre, bir CASE aracı aynı kriterler kullanılarak bir grup uzman tarafından değerlendirilmelidir. Bireylerin veya ekiplerin gerekli uzmanlık düzeyi önceden belirlenmelidir.

Değerlendirmenin sonuçları standart bir şekilde (sonraki kullanımı kolaylaştırmak için) belgelenmeli ve gerekirse doğrulanmalıdır.

Değerlendirme raporu aşağıdaki bilgileri içermelidir:

  • giriiş. Sürece genel bir bakış ve ana çıktıların listesi;
  • arka plan. Değerlendirmenin amacı ve istenen sonuçlar, değerlendirmenin yürütüldüğü süre, değerlendirmeyi yapan uzmanların rollerinin tanımı ve ilgili deneyimleri;
  • değerlendirme yaklaşımı. Elde edilen CASE araçları, değerlendirmenin bağlamını ve kapsamını tanımlayan bilgiler ve tüm varsayımlar ve sınırlamalar dahil olmak üzere genel yaklaşımın açıklaması;
  • CASE araçları hakkında bilgi. Aşağıdakileri içermelidir: 1) CASE aracının adı; 2) CASE aracı sürümü; 3) iletişim adresi ve telefon numarası dahil olmak üzere tedarikçinin ayrıntıları; 4) teknik araçların konfigürasyonu; 5) maliyet verileri; 6) CASE aracının açıklaması, bu araç tarafından desteklenen yazılım oluşturma ve bakım süreçleri, CASE aracı yazılım ortamı (özellikle desteklenen programlama dilleri, işletim sistemleri, veritabanı uyumluluğu), CASE aracı işlevleri, giriş/çıkış verileri ve alan uygulamaları;
  • değerlendirme adımları. Değerlendirme sürecine dahil olan belirli faaliyetler, hem değerlendirmenin kapsamını ve derinliğini anlamak hem de gerekirse tekrarlamak için gerekli ayrıntı düzeyinde tanımlanmalıdır;
  • somut sonuçlar. Değerlendirme sonuçları, değerlendirme kriterleri açısından sunulmalıdır. Raporun kapsadığı yerler tüm çizgi CASE araçları veya bu değerlendirmenin sonuçları diğer değerlendirmelerin benzer sonuçlarıyla karşılaştırılacaktır, lütfen iletişime geçin Özel dikkat bu karşılaştırmayı kolaylaştıran bir sunum formatında. Subjektif sonuçlar objektif olanlardan ayrılmalı ve gerekli açıklamalarla birlikte sunulmalıdır;
  • sonuçlar ve sonuçlar;
  • uygulamalar. Değerlendirme görevinin formülasyonu ve güncellenmiş bir kriter listesi.

Değerlendirme ve seçim süreçleri birbiriyle yakından ilişkilidir. Değerlendirmenin sonuçlarına göre, seçim hedefleri ve/veya seçim kriterleri ve bunların ağırlıklarının değiştirilmesi gerekebilir. Bu gibi durumlarda yeniden değerlendirme gerekebilir. Nihai değerlendirme sonuçları analiz edildiğinde ve bunlara seçim kriterleri uygulandığında, bir CASE aracının veya bir CASE araçları setinin satın alınması önerilebilir. Bir alternatif, yeterli CASE araçlarının olmaması olabilir; bu durumda yeni bir CASE aracı geliştirmeniz, mevcut bir aracı değiştirmeniz veya uygulamadan vazgeçmeniz önerilir.

Seçim süreci, değerlendirme süreci ile yakından ilgilidir ve aşağıdaki adımları içerir:

  • hedefler, varsayımlar ve kısıtlamalar dahil olmak üzere seçim hedeflerinin formülasyonu;
  • kriterlerin tanımlanması ve sıralanması, aday fonların belirlenmesi, gerekli verilerin toplanması ve sıralanan kriterlerin fonların belirlenmesi için değerlendirme sonuçlarına uygulanması dahil olmak üzere gerekli tüm seçim işlemlerinin gerçekleştirilmesi en iyi performans. Birçok kullanıcı için önemli kriter tercih edilen CASE aracının mevcut ortamla bütünleştirilebilirliğidir;
  • benzer göstergelere sahip araçları seçmek (veya reddetmek) için gerekli sayıda yinelemenin gerçekleştirilmesi;
  • seçim sonuçlarına ilişkin bir raporun hazırlanması.

Seçim sürecinde iki olası sonuç vardır:

  • belirli bir CASE aracının seçilmesine yönelik öneriler;
  • değerlendirme süreci için ek bilgi talebi.

Seçim ölçeği, gerekli detay seviyesini, gerekli kaynakları, programı ve beklenen sonuçları belirlemelidir. Aşağıdakiler de dahil olmak üzere ölçeği belirlemek için kullanılabilecek bir dizi parametre vardır:

  • ön seçimin kullanılması (örneğin, yalnızca belirli bir platformda çalışan fonların seçilmesi);
  • önceden elde edilen değerlendirme sonuçlarının kullanılması, dış kaynaklar veya her ikisinin kombinasyonları;

Önceki değerlendirmelerin farklı ölçüt grupları kullanılarak veya belirli ölçütler kullanılarak ancak farklı şekillerde gerçekleştirilmesi durumunda, değerlendirmelerin sonuçları tutarlı bir şekilde sunulmalıdır. Bu adım tamamlandıktan sonra, her bir CASE aracının puanı tek bir ölçüt grubu altında sunulmalı ve diğer puanlarla doğrudan karşılaştırılabilir olmalıdır.

Seçim için yaygın olarak kullanılan algoritmalar, ölçeğe veya sıralamaya dayalı olabilir. Ölçeğe dayalı algoritmalar, her bir CASE tesisi için her bir kriterin ağırlığını değeriyle çarparak (ölçeği dikkate alarak) ve tüm ürünleri toplayarak tek bir değer hesaplar. En yüksek puana sahip CASE aracı birinci sırayı alır. Dereceye dayalı algoritmalar, aday CASE araçlarının, belirli bir ölçekteki kriterlerin değerlerine göre bireysel kriterlere veya kriter gruplarına göre sıralamasını kullanır. Ardından bir öncekine benzer şekilde ranklar bir araya getirilerek toplam rank değerleri hesaplanır.

Seçim sonuçları analiz edilirken seçim sürecinin tamamlandığı varsayılır, CASE aracı seçilir ve kullanılması önerilir. Ancak, daha fazla sürebilir kesin analiz anahtar kriterlerin değerlerinin, CASE araçlarının - adayların özelliklerinin değerlerindeki farklılıklara bağımlılık derecesini belirlemek. Böyle bir analiz, CASE-ortalama sıralamasının sonucunun, kriter ağırlık katsayılarının optimal seçimine ne ölçüde bağlı olduğunu belirlemeyi mümkün kılacaktır. Çok benzer kriter değerlerine veya sıralarına sahip CASE araçları arasındaki önemli farklılıkları belirlemek için de kullanılabilir.

CASE araçlarından hiçbiri minimum kriterleri karşılamıyorsa, diğer aday CASE araçları için seçim (belki puanla birlikte) tekrar edilebilir.

En çok tercih edilen adaylar arasındaki farklar anlamlı değilse, Ek Bilgiler ek veya farklı kriterler kullanılarak yeniden seçim (muhtemelen bir puanla birlikte) ile elde edilebilir.

Seçim önerileri kesinlikle gerekçelendirilmelidir. Yeterli CASE araçlarının yokluğunda, yukarıda belirtildiği gibi, yeni bir CASE aracı geliştirmeniz, mevcut olanı değiştirmeniz veya uygulamadan vazgeçmeniz önerilir.

Kriterler, değerlendirme ve seçim süreçleri için temel oluşturur ve aşağıdakiler de dahil olmak üzere pek çok biçimde olabilir:

  • gereken bellek miktarı gibi çok çeşitli değerlerde sayısal ölçümler;
  • sınırlı bir değer aralığındaki sayısal ölçümler, örneğin, 1'den 5'e kadar puanlarla ifade edilen öğrenme kolaylığı;
  • Postscript formatında dokümantasyon oluşturma yeteneği gibi ikili ölçümler (doğru/yanlış, evet/hayır);
  • CASE tesisinin desteklendiği platformlar gibi bir veya daha fazla sonlu değer kümesinin alabileceği önlemler.

Tipik bir değerlendirme ve/veya seçim süreci, bir dizi farklı türde kriter kullanabilir.

Bir dizi kriterin yapısı Şekil 2'de gösterilmektedir. Her kriter, belirli bir sürecin özellikleri dikkate alınarak bir uzman tarafından seçilmeli ve uyarlanmalıdır. Çoğu durumda, aşağıda açıklanan birçok kriterden yalnızca bazıları kabul edilebilir ve ek kriterler de eklenir. Kullanılacak kriter setinin seçilmesi ve rafine edilmesi, değerlendirme ve/veya seçim sürecinde kritik bir adımdır.

Birinci sınıfın kriterleri, CASE aracının işlevsel özelliklerini belirlemeye yöneliktir. Sırayla, bir dizi gruba ve alt gruba ayrılırlar.

Proje ortamı:

- yaşam döngüsü süreçleri için destek. CASE aracının desteklediği yaşam döngüsü süreçleri kümesini tanımlar. Bu tür süreçlere örnek olarak gereksinim analizi, tasarım, uygulama, test ve değerlendirme, bakım, kalite güvencesi, konfigürasyon yönetimi ve proje yönetimi verilebilir ve bunlar kullanıcı tarafından benimsenen yaşam döngüsü modeline bağlıdır.

- uygulama alanıÖrnekler, işlem işleme sistemleri, gerçek zamanlı sistemler, bilgi sistemleri vb.

- desteklenen uygulama boyutu. Kod satırı sayısı, iç içe geçme düzeyleri, veritabanı boyutu, veri öğesi sayısı, yapılandırma yönetimi nesnesi sayısı gibi değerler üzerinde sınırlar tanımlar.

İLE/ teknik araçlar:

- gerekli teknik araçlar. İşlemci türü, RAM miktarı ve disk belleği dahil olmak üzere CASE aracının çalışması için gerekli ekipman.

- desteklenen teknik araçlar. G/Ç aygıtları gibi CASE aracı tarafından kullanılabilen donanım öğeleri.

- gerekli yazılım. İşletim sistemleri ve grafik kabuklar dahil olmak üzere CASE aracının çalışması için gerekli yazılımlar.

- desteklenen yazılım. CASE aracı tarafından kullanılabilen yazılım ürünleri.

Pirinç. 2. Bir dizi kriterin yapısı

Teknolojik ortam:

- proses ortamı standartlarına uygunluk. Bu tür standartlar, dil, veri tabanı, havuz, iletişim, grafik kullanıcı arayüzü, dokümantasyon, geliştirme, konfigürasyon yönetimi, güvenlik, iletişim standartları ve veri, kontrol ve kullanıcı arayüzü entegrasyonu ile ilgilidir.

- diğer araçlarla uyumluluk. Doğrudan veri alışverişi dahil olmak üzere diğer araçlarla etkileşime girme yeteneği (bu tür araçlara örnek olarak kelime işlemciler, veritabanları ve diğer CASE araçları verilebilir). Bir depoyu veya bir kısmını başka yollarla işlemek için standart bir biçime dönüştürme yeteneği.

- desteklenen metodoloji. CASE aracı tarafından desteklenen yöntem ve teknikler kümesi. Örnekler, yapısal veya nesne yönelimli analiz ve tasarımdır.

- desteklenen diller. CASE aracı tarafından kullanılan tüm diller. Bu tür dillere örnek olarak programlama dilleri (Cobol, Ada, C), veritabanı ve sorgulama dilleri (DDL, SQL), grafik dilleri (Postscript, HPGL), proje gereksinimleri belirleme dilleri ve işletim sistemi arayüzleri gösterilebilir. (iş kontrol dilleri).

Modelleme:
Bu kriterler, yazılım gereksinimlerini belirlemek ve bunları bir projeye dönüştürmek için gerekli işlevleri gerçekleştirme yeteneğini belirler:

- diyagram oluşturma. Kullanıcının ilgi alanına giren çeşitli türlerde diyagramlar oluşturma ve düzenleme yeteneği. En yaygın grafik türleri Bölüm 2'de açıklanmıştır.

- grafik analiz. Grafik nesneleri analiz etme ve tasarım bilgilerini grafiksel bir sunumda saklama ve sunma becerisi. Çoğu durumda, grafik analizörler, grafik oluşturma araçlarıyla entegre edilmiştir.

- gereksinim belirtimlerinin ve tasarım belirtimlerinin girilmesi ve düzenlenmesi. Bu tür spesifikasyonlar, fonksiyonların, verilerin, arayüzlerin, yapının, kalitenin, performansın, tesislerin, ortamın, maliyetlerin ve programların açıklamalarını içerir.

- gereksinim belirtimi ve tasarım belirtim dili. Resmi bir dil kullanarak spesifikasyonları içe aktarma, dışa aktarma ve düzenleme yeteneği.

- veri modelleme. Sistem veri öğelerini ve bunların ilişkilerini açıklayan bilgileri girme ve düzenleme yeteneği.

- süreç modelleme. Sistem süreçlerini ve bunların ilişkilerini açıklayan bilgileri girme ve düzenleme yeteneği.

- yazılım mimarisi tasarımı. Yazılımın mantıksal yapısının tasarlanması - modüllerin yapısı, arayüzler vb.

- simülasyon modelleme. Dinamik simülasyon yeteneği çeşitli yönlerön uç ve performans (ör. yanıt süresi, kaynak kullanımı ve iş hacmi) dahil olmak üzere gereksinimlere ve/veya tasarım özelliklerine dayalı sistem performansı.

- prototipleme Gereksinim belirtimlerine ve/veya tasarım belirtimlerine dayalı olarak tüm sistemin veya tek tek bileşenlerinin bir ön sürümünü tasarlama ve oluşturma yeteneği. Prototipleme esas olarak harici kullanıcı arayüzü ile ilgilidir ve kullanıcıların doğrudan katılımıyla gerçekleştirilir.

- ekran formu oluşturma. Gereksinim özelliklerine ve/veya tasarım özelliklerine göre ekran formları oluşturma yeteneği.

- izleme yeteneği. Gereksinimlerin belirlenmesinden nihai sonuçlara kadar sistemin işleyişinin uçtan uca analiz edilmesi olasılığı (fonksiyonel ve diğer arasındaki yazışmaların ve ilişkilerin kurulması ve izlenmesi) dış gereksinimler IP'ye, teknik çözümlere ve tasarım sonuçlarına). İleri izleme (tüm gereksinimlerin dikkate alınıp alınmadığının kontrol edilmesi) ve geriye doğru izleme (herhangi bir dış gereksinimle ilgili olmayan tasarım çözümlerinin araştırılması).

- tasarım özelliklerinin sözdizimsel ve anlamsal kontrolü. Diyagramların sözdizimini ve öğelerinin türlerini kontrol etme, fonksiyonların ayrışmasını kontrol etme, tamlık ve tutarlılık için spesifikasyonları kontrol etme.

- diğer analiz türleri. Spesifik ek analizler, algoritmaları, veri akışlarını, veri normalleştirmeyi, veri kullanımını, kullanıcı arayüzünü içerebilir.

- raporların otomatik tasarımı.

Uygulama:
Uygulama, sistemin yürütülebilir öğelerinin (program kodları) oluşturulması veya mevcut bir sistemin değiştirilmesi ile ilgili işlevleri etkiler. Aşağıda listelenen kriterlerin çoğu dile özgüdür ve aşağıdakileri içerir:

- sözdizimsel kontrollü düzenleme. Eşzamanlı sözdizimsel kontrol ile bir veya daha fazla dilde kaynak kodlarını girme ve düzenleme yeteneği.

- kod üretimi. Tasarım özelliklerine göre bir veya daha fazla dilde kod üretebilme. Üretilen kod türleri, normal program kodunu, veritabanı şemasını, sorguları, ekranları/menüleri içerebilir.

- kodu derlemek.

- kaynak kodu dönüştürme. Kodu bir dilden diğerine dönüştürme yeteneği.

- Güvenilirlik analizi. Hata sayısı vb. gibi yazılım güvenilirlik parametrelerini ölçme yeteneği.

- tersine mühendislik. Mevcut kaynak kodlarını analiz etme ve bunlara dayalı tasarım özellikleri oluşturma becerisi.

- kaynak kodu yeniden yapılandırma. Mevcut kaynak kodunun biçimini ve/veya yapısını değiştirme yeteneği.

- kaynak kodu analizi. Bu tür analiz örnekleri, kod boyutu belirleme, karmaşıklık puanı hesaplama, çapraz referans oluşturma ve standart kontrolüdür.

- hata ayıklama. Tipik hata ayıklama özellikleri, programları izleme, darboğazları ve en sık kullanılan kod parçalarını vb. vurgulamadır.

Test yapmak:
Test kriterleri aşağıdakileri içerir:

- test açıklaması. Tipik yetenekler, test verileri, test algoritmaları, gerekli sonuçlar vb. oluşturmayı içerir.

- operatör eylemlerini sabitleme ve tekrarlama. Operatör tarafından klavye, fare vb. kullanılarak girilen verileri yakalama, bunları düzenleme ve test durumlarında çoğaltma yeteneği.

- test durumlarının otomatik olarak başlatılması.

- gerileme testi. Sistem ve/veya ortamdaki farklılıkları belirlemek için daha önce gerçekleştirilen testleri tekrarlama ve değiştirme yeteneği.

- test sonuçlarının otomatik analizi. Tipik özellikler, beklenen ve gerçek sonuçların karşılaştırılmasını, dosya karşılaştırmasını, sonuçların istatistiksel analizini vb. içerir.

- test kapsamı analizi. Kaynak kodu kontrol araçları ve test kapsamı analizi ile donatılmıştır. Özellikle operatörlere yapılan çağrılar, prosedürler ve değişkenler kontrol edilir.

- performans analizi. Programların performansını analiz edebilme. Analiz edilen performans parametreleri CPU kullanımını, bellek kullanımını, belirli veri öğelerine ve/veya kod bölümlerine erişimi, zamanlamayı vb. içerebilir.

- test sürecinde istisnai durumların analizi.

- ortamın dinamik modellemesi.Özellikle, simüle edilmiş sistem girdilerini otomatik olarak oluşturma yeteneği.

Aşağıdaki kriterler, yaşam döngüsünün tüm aşamalarını kapsayan CASE araçlarının işlevlerini tanımlar. Tüm bu işlevler depo aracılığıyla desteklenir.

Belgeler:

- metinleri ve grafikleri düzenleme. Metin ve grafik biçiminde veri girme ve düzenleme yeteneği.

- formlarla düzenleme. Kullanıcı tanımlı formları destekleme, formlara göre veri girme ve düzenleme yeteneği.

- yayınlama yetenekleri.

- köprü metni işlevleri ve biçimleri için destek.

- dokümantasyon standartlarına uygunluk.

- Veri havuzundan verilerin otomatik olarak çıkarılması ve kullanıcı özelliklerine göre belgelerin oluşturulması.

Konfigürasyon yönetimi:

- erişim ve değişiklik kontrolü. Veri öğelerine fiziksel düzeyde erişimi kontrol etme ve kontrolü değiştirme yeteneği. Erişim kontrolü, bileşenlere erişim haklarını belirleme, değişiklik için veri öğelerini çıkarma, değişiklik sırasında bunlara erişimi engelleme ve depoya geri yerleştirme yeteneğini içerir.

- değişiklik takibi. Geliştirme veya bakım sırasında sistemde yapılan tüm değişikliklerin kaydedilmesi ve günlüğe kaydedilmesi.

- sürüm kontrolü. Sistemin ve tüm paylaşılan bileşenlerinin sürüm verilerinin bakımı ve kontrolü.

- yapılandırma yönetimi nesnelerinin durumunun muhasebeleştirilmesi. Çeşitli yapılandırma yönetimi nesnelerinin ardışık tüm sürümleri, içeriği ve durumu hakkında rapor verme yeteneği.

- sürümlerin oluşturulması ve modifikasyonlar. Sürümleri ve değişiklikleri oluşturmak için gerekli eylem dizisinin kullanıcı açıklaması ve bu eylemlerin otomatik olarak yürütülmesi için destek.

- arşivleme. Veri öğelerini daha sonra kullanmak üzere otomatik olarak arşivleme yeteneği.

Proje Yönetimi:

- iş ve kaynak yönetimi. IS tasarım sürecinin görevlerin yapısı ve icracıların atanması, uygulama sırası, projenin bireysel aşamalarının tamamlanması ve bir bütün olarak proje açısından kontrolü ve yönetimi. Planlanan verileri, gerçek verileri ve bunların analizlerini destekleyebilme. Tipik veriler programları (takvimi, çalışma saatlerini, tatilleri vb. hesaba katarak), bilgisayar kaynaklarını, personel dağılımını, bütçeyi vb. içerir.

- seviye. Kullanıcılar tarafından girilen maliyetleri, programı ve diğer tasarım parametrelerini değerlendirebilme.

- test prosedürü yönetimi. Planlanan prosedürlerin zamanlamasını yönetme, test sonuçlarını sabitleme ve kaydetme, raporlar oluşturma vb. gibi prosedürlerin ve test programının yönetimine yönelik destek.

- kalite kontrol. İlgili verilerin girilmesi, analiz edilmesi ve raporların oluşturulması.

- düzeltici eylemler. Sorun raporlama dahil olmak üzere düzeltici eylem yönetimi desteği.

Güvenilirlik

  • depo yönetimi. Tasarım verilerinin bütünlüğünü kontrol edin ve sağlayın.
  • otomatik artıklık (sağlayıcı tanımlı veya kullanıcı planlı).
  • emniyet. Yetkisiz erişime karşı koruma.
  • hata işleme. Sistemin işleyişindeki hataların tespiti, kullanıcıya bildirilmesi, kesinti anında incelikle kapatılması veya durumun kaydedilmesi.
  • Kritik uygulamalarda hata analizi.

Kullanım kolaylığı

  • kullanıcı arayüzünün rahatlığı. Sık kullanılan ekran öğelerinin, veri giriş yöntemlerinin vb. uygun düzeni ve sunumu.
  • yerelleştirme (belirli bir ülkenin gereksinimlerine göre).
  • öğrenme kolaylığı. Fonların geliştirilmesi için emek ve zaman maliyetleri.
  • belirli kullanıcı gereksinimlerine uyarlanabilirlik. Farklı alfabelere, metin ve grafik sunum modlarına (soldan sağa, yukarıdan aşağıya), farklı tarih formatlarına, giriş/çıkış yöntemlerine (ekran formları ve formatları), metodolojideki değişikliklere (grafik gösterimlerdeki değişiklikler, kurallar) uyarlanabilirlik , önceden tanımlanmış nesnelerin özellikleri ve bileşimi) vb.
  • dokümantasyonun kalitesi (tamlık, anlaşılabilirlik, okunabilirlik, kullanışlılık, vb.).
  • eğitim materyallerinin mevcudiyeti ve kalitesi. Bilgisayar içerebilirler eğitim materyalleri, çalışma kılavuzları, dersler.
  • bilgi düzeyi gereksinimleri. CASE araçlarını etkili bir şekilde kullanmak için gereken nitelikler ve deneyim.
  • CASE aracıyla çalışma kolaylığı (hem yeni başlayanlar hem de deneyimli kullanıcılar için).
  • kullanıcı arayüzünün birleştirilmesi (bu organizasyonda kullanılan diğer araçlarla ilgili olarak).
  • çevrimiçi ipuçları (tamlık ve kalite).
  • teşhis kalitesi (kullanıcı için teşhis mesajlarının anlaşılırlığı ve kullanışlılığı).
  • kullanıcı eylemlerine izin verilen yanıt süresi (ortama bağlı olarak).
  • Sürümleri yüklemek ve güncellemek kolaydır.

Yeterlik

  • teknik gereksinimler. Kabul edilebilir bir performans düzeyi sağlayan, harici ve RAM'in optimum boyutu, işlemcinin tipi ve performansı için gereksinimler.
  • iş yükü verimliliği. Kullanıcının işinin yoğunluğuna bağlı olarak (örneğin, belirli işlevleri gerçekleştirmek için gereken tuş vuruşlarının veya fare düğmelerinin sayısı) bir CASE aracının işlevlerini ne kadar verimli bir şekilde yerine getirdiği.
  • verim. CASE aracının belirli görevleri gerçekleştirmek için harcadığı süre (örneğin, sorgu yanıt süresi, 100.000 satırlık kodun ayrıştırma süresi). Bazı durumlarda, performans değerlendirme verileri dış kaynaklardan elde edilebilir.

sürdürülebilirlik

  • satıcının destek düzeyi (sorun çözme hızı, yeni sürümlerin teslimi, ek özelliklerin sağlanması).
  • güncellemelerin izlenebilirliği (yeni sürümler ile mevcut sürümler arasındaki farkları öğrenme kolaylığı).
  • güncelleme uyumluluğu (örneğin, giriş veya çıkış uyumluluğu dahil olmak üzere yeni sürümlerin mevcut sürümlerle uyumluluğu).
  • Nihai ürünün sürdürülebilirliği (yazılım ve belgelerde değişiklik yapma kolaylığı).

taşınabilirlik

  • işletim sistemi sürümleriyle uyumluluk (aynı işletim sisteminin farklı sürümlerinin bulunduğu bir ortamda çalışabilme, CASE aracını yeni işletim sistemi sürümleriyle çalışacak şekilde değiştirme kolaylığı).
  • CASE aracının farklı sürümleri arasında verilerin taşınabilirliği.
  • taşınabilirlik standartları Bu tür standartlar dokümantasyon, iletişim ve kullanıcı arabirimi, pencere arabirimi, programlama dilleri, sorgulama dilleri vb. içerir.

Seçilen CASE aracının kuruluşta tam ölçekli uygulamasından önce, amacı önceki aşamalarda alınan kararların doğruluğunu deneysel olarak doğrulamak ve uygulamaya hazırlanmak olan bir pilot proje yürütülür.

Bir pilot proje, CASE aracının amaçlanan ortamda ilk gerçek kullanımını temsil eder ve genellikle CASE aracının değerlendirme sırasında elde edilenden daha geniş bir ölçekte kullanımını içerir. Bir pilot proje, aracın amaçlandığı gerçek projelerin birçok özelliğine sahip olmalıdır. Aşağıdaki hedeflere sahiptir:

  • değerlendirme ve seçim sonuçlarının güvenilirliğini teyit etmek;
  • Bir CASE aracının belirli bir organizasyonda kullanım için gerçekten uygun olup olmadığını belirleyin ve eğer öyleyse, uygulaması için en uygun kapsamı belirleyin;
  • pratik uygulama için bir plan geliştirmek için gerekli bilgileri toplamak;
  • CASE aracını kullanma konusunda kendi deneyiminizi kazanın.

Pilot proje şunları sağlar: önemli bilgi araç yüklendikten sonra CASE aracının performansını ve satıcı desteğini değerlendirmek için gereklidir.

önemli işlev pilot proje, CASE aracının edinilmesi veya kullanılmasının reddedilmesi ile ilgili bir karar vermektir. Bir pilot projenin başarısızlığı, daha sonra daha büyük ve daha maliyetli başarısızlıkları önler, çünkü bir pilot proje genellikle nispeten küçük bir projenin satın alınmasını içerir. Büyük bir sayı dar bir uzman çemberinin lisansları ve eğitimi.

Bir pilot projede yeni bir CASE teknolojisinin ilk kullanımı dikkatlice planlanmalı ve kontrol edilmelidir. Pilot proje aşağıdaki adımları içermektedir (Şekil 3).

Pilot proje aşağıdaki özelliklere sahip olmalıdır:

  • uygulama alanı. CASE aracının kapsamının nihai tanımını kolaylaştırmak için pilot projenin konu alanı, kuruluşun normal faaliyetlerini temsil etmelidir. Pilot proje, pilot projeden tesisin yaygın kullanımına geçmek için gereken ek teknoloji, eğitim veya desteğin belirlenmesine yardımcı olmalıdır. Bu kısıtlamalar dahilinde, pilot proje küçük ama anlamlı olmalıdır.
  • ölçeklenebilirlik. Pilot projede elde edilen sonuçlar, aracın ölçeklenebilirliğini göstermelidir. Amaç, bu aracın geçerli olduğu projelerin kapsamı hakkında net bir fikir edinmektir.

Pirinç. 3. Pilot projenin adımları

  • temsil edilebilirlik. Bir pilot proje alışılmadık veya kuruluşa özgü olmamalıdır. Tüm kuruluş tarafından iyi anlaşılan bir konu alanıyla ilgili sorunları çözmek için bir CASE aracı kullanılmalıdır.
  • kritiklik. Bir pilot proje, ilgi odağı olmak için önemli olmalı, ancak bir bütün olarak organizasyonun başarısı için kritik olmamalıdır. Yeni bir teknolojinin ilk tanıtımının bazı riskler içerdiği kabul edilmelidir. Pilot proje seçerken şu ikilemi çözmek gerekiyor: Küçük bir projenin başarısı gözden kaçabilir, öte yandan önemli bir projenin başarısızlığı aşırı eleştiriye neden olabilir.
  • Yetki. Projede yer alan uzman grubu yüksek yetkiye sahip olmalıdır, projenin sonuçları ise organizasyonun geri kalanı tarafından ciddiye alınacaktır.
  • Özellikler proje takımı . Proje ekibi yenilikçi, teknik olarak olgun ve teknoloji ve konu alanında kabul edilebilir düzeyde deneyim ve bilgiye sahip olmalıdır. Öte yandan grup, bir bütün olarak tüm organizasyonun özelliklerini minyatür olarak yansıtmalıdır.

Çoğu durumda, ideal bir pilot projeyi uygulama arzusu ile kuruluşun gerçek sınırlamaları arasında bir denge vardır. Kuruluş, bir pilot projeyi, ilk olarak, CASE aracının içinde kullanım şeklinin gelecek planları ile örtüşecek ve ikinci olarak, yukarıda sıralanan özellikler, kuruluşun gerçek koşulları ile dengelenecek şekilde seçmelidir.

Ayrıca kuruluş, pilot projenin süresini (ve genel uygulama sürecini) dikkate almalıdır. Çok uzun bir proje, yönetimin projeye olan ilgisini kaybetme riskiyle ilişkilidir.

Pilot proje planlaması, kuruluşun normal proje planlama sürecine mümkün olduğunca uymalıdır. Plan aşağıdaki bilgileri içermelidir:

  • hedefler, hedefler ve değerlendirme kriterleri;
  • kadro;
  • prosedürler ve anlaşmalar;
  • eğitim;
  • zamanlama ve kaynaklar.

Amaçlar, hedefler ve değerlendirme kriterleri

Pilot projenin beklenen sonuçları açıkça tanımlanmalıdır. Bu sonuçlara uygunluk derecesi, projenin müteakip değerlendirmesi için temel oluşturur. Amaçları, hedefleri ve değerlendirme kriterlerini belirlemek için aşağıdaki adımları gerçekleştirmelisiniz:

· projeyi beklenen sonuçlar açısından tanımlayın(yani nihai ürün). Açıklama, sunum şeklini ve sonuçların içeriğini içermelidir. Sözleşme gereklilikleri ve ilgili standartlar açıkça tanımlanmalıdır.

· projenin genel hedeflerini tanımlayın. Bir hedef örneği, CASE araçlarının kullanımının bir sonucu olarak proje dokümantasyonunun kalitesindeki gelişme derecesini belirlemek olabilir.

· hedefleri gerçekleştiren belirli görevleri tanımlayın. Her hedef, ölçülebilir sonuçları olan bir veya daha fazla spesifik hedefle ilişkilendirilebilir. Böyle bir görevin bir örneği, bir CASE aracı kullanılarak ve onsuz elde edilen belgelerin kalitesinin karşılaştırmalı bir analizi olabilir. Dokümantasyon, yazılım gereksinimleri belirtimini, üst düzey ve ayrıntılı tasarım belirtimlerini içerebilir.

· sonuçları değerlendirmek için kriterleri tanımlayın. Bir pilot projenin başarı derecesini belirlemek için yukarıda belirtilen görevlere dayalı bir dizi kriter kullanılmalıdır. Bir kriter örneği, proje dokümantasyonunun tutarlılık derecesi ve yazılım gereksinimlerinin uygulanmasının kontrol edilebilirliği olabilir. Kriter değerleri, pilot proje öncesinde elde edilen temel değerler ile karşılaştırılmalıdır.

Kadro

Pilot projeye katılmak üzere seçilen kişiler, uygun yetkiye ve etkiye sahip olmalı ve yeni teknolojinin destekçisi olmalıdır. Ekip, yeni teknolojiyle ilgilenen ve onu nasıl kullanacağını anlayan hem teknik kişileri hem de yöneticileri içermelidir. Grup, yüksek iletişim becerilerine, örgütsel süreçler ve prosedürler ile konu alanına ilişkin bilgiye sahip olmalıdır. Ancak grup tamamen üst düzey profesyonellerden oluşmamalı, organizasyonun orta düzeyini temsil etmelidir.

Birçok CASE aracı, proje dokümantasyonu oluşturma ve yapılandırma yönetimi ile ilgili yetenekler sağlar. Bunlarla ve yazılım geliştirme ve bakımın diğer ilgili yönleriyle ilişkili uzmanlar da gruba dahil edilmelidir.

Pilot projenin tamamlanmasından sonra grup, yeni aracın yetenekleri ve onu kullanmaktan elde edilen deneyim hakkında kuruluşun geri kalanıyla bilgi paylaşmaya açık olmalıdır. Deneyimlerini ve bilgilerini yaymak için proje ekibi üyelerini kuruluş içinde dağıtmak istenebilir.

Prosedürler ve anlaşmalar

Pilot projede CASE araçlarının kullanımına ilişkin prosedürler ve anlaşmalar açıkça tanımlanmalıdır. Bu görev muhtemelen beklenenden daha uzun ve karmaşık olacaktır ve dışarıdan uzmanların dahil edilmesi gerekebilir. Bir pilot projenin başarısını etkileyebilecek prosedürlere ve anlaşmalara örnek olarak metodoloji, teknik anlaşmalar (özellikle adlandırma ve dizin yapısı, tasarım ve programlama standartları - bkz. alt bölüm 1.3) ve kurumsal anlaşmalar (özellikle, kaynak kullanımının muhasebesi, yetki , değişiklik kontrolü, gözden geçirme ve raporlama prosedürleri, kalite güvence standartları).

Pilot proje, mümkün olan her yerde kuruluşun prosedürlerini ve sözleşmelerini kullanmalıdır. Öte yandan, bir pilot proje sırasında, araçla ilgili deneyim kazanıldıkça prosedürler ve anlaşmalar gelişme ve iyileşme eğilimi gösterir. Mevcut prosedürler ve anlaşmalar etkisiz veya aşırı derecede kısıtlayıcı olabilir. Aynı zamanda, bunlarda yapılması önerilen değişiklikler belgelenmelidir.

Eğitim

Pilot projeyi yürütmek için gereken eğitim türleri ve miktarı belirlenmelidir. Eğitimi planlarken akılda tutulması gereken üç tür ihtiyaç vardır: teknik, yönetimsel ve motivasyonel. Eğitim için gereken kaynaklar (sınıflar ve ekipman, öğretmenler ve öğretim materyalleri) pilot proje planına uygun olmalıdır.

Eğitim programı, hem eğitilecek profesyonelleri hem de almaları gereken eğitim türlerini tanımlamalıdır. Proje süresince yer alan eğitim, proje başladıktan sonra mümkün olan en kısa sürede başlamalıdır. Projenin başlamasından sonraki birkaç ay içinde kullanılmayacak olan araçlara, süreçlere veya yöntemlere ilişkin eğitim, gerçekten ihtiyaç duyuldukları zaman için planlanmalıdır.

CASE aracı satıcıları genellikle sağladıkları araçların nasıl kullanılacağına ilişkin eğitim sunar. Ayrıca bazı araçlar için metodoloji eğitimi gerekebilir. Bazı eğitim türleri yapılmalıdır kendi başlarına. Bu öğrenme türleri, organizasyonda yer alan süreçler bağlamında ve ayrıca bu ortamdaki diğer araçlarla bağlantılı olarak bir CASE aracının kullanımını içerir. Pilot proje planının eğitim kısmı, uygulama planına girdi olarak kullanılmalıdır.

Gerekli eğitimin seçiminde aşağıdaki faktörler dikkate alınmalıdır:

  • öğretmen nitelikleri;
  • eğitimin belirli uzman gruplarının özelliklerine uygunluğu (on-
    örneğin, yöneticiler için genel bakış kursları, geliştiriciler için ayrıntılı kurslar);
  • doğrudan işyerinde ders verme imkanı;
  • genişletilmiş kurslar yürütme olasılığı;
  • kendi öğretmenlerini yetiştirme imkanı.

Program ve Kaynaklar

Yürütülecek iş için kaynakları ve zaman dilimlerini (aşamaları) içeren bir program geliştirilmelidir. Kaynaklar personel, donanım, yazılım ve finansmanı içerir. Personel verileri, bir pilot projeyi başarıyla tamamlamak için gereken belirli becerileri veya beceri gereksinimlerini tanımlayabilir. Finansman, her iş türü için ayrı ayrı belirlenmelidir: CASE araçlarının satın alınması, kurulum, eğitim, bireysel tasarım aşamaları.

Sonuç olarak, bireysel CASE araçlarını karşılaştırmanın uygunsuzluğuna bir kez daha dikkat çekmek isterim, çünkü bunların hiçbiri genel olarak yazılım oluşturma ve sürdürmenin tüm sorunlarını çözmez. Bu ayrıca, yazılım yaşam döngüsünün tüm aşamalarını etkileyen eksiksiz bir değerlendirme ve seçim kriterleri seti ile de doğrulanır. Yazılımın tüm yaşam döngüsünü destekleyen ve gerekli teknik ve metodolojik destekle sağlanan, metodolojik ve teknolojik olarak koordineli araçlardan oluşan kompleksler karşılaştırılabilir.

Tüm bunlara dayanarak, tasarım sürekli olarak yeni öğeler eklediğinden ve bilgi teknolojileri giderek daha fazla yeni özellik kazandığından, metodolojinin hızlı bir şekilde geliştiği, yeni IS tasarım araçları edindiği ve geliştirdiği sonucuna varabiliriz.

Kurs çalışması sırasında, çalıştım ve düşündüm:

1. CASE değerlendirmesi yapmak.

2. Süreci öğrendim VAKA seçimi- para kaynağı.

3. CASE - fonlarının değerlendirilmesi ve seçimi için kriterleri öğrendi.

Çalışma sırasında, hangi bilgi sistemleri sınıflarının var olduğunu (örneğin, manuel, otomatik ve otomatik gibi), bu sınıfların nasıl ve neye dayandığını ve her birinin özel olarak yanı sıra bunların kullanımını ortaya çıkardım. tasarım ve programlama dersleri.

Çalışmadan, bu CASE araçlarının değerlendirilmesi ve seçimine ilişkin tasarımın modern ilkelerinin ve özelliklerinin yapısal analiz, nesne yönelimli modelleme, CASE sistemlerinin kullanımına dayandığı anlaşılmaktadır.

1. Alekseev A.A., Popenko R.A. Bilgi sistemindeki CASE araçları - St. Petersburg: UNITI, 2003.

2. Barkın R.S. CASE yöntemi. Modelleme - M: Merkez, 2003.

3. Vendrov A.M. Veritabanları ve uygulamalar için tasarım araçlarının seçimine yönelik yaklaşımlardan biri // DBMS - 2003. - No. 3.

4. Vendrov A.M. Ekonomik sistemler için yazılım tasarlama - M.: Finans ve istatistik, 2005.

5. Vendrov A.M. UML dili ve Rational Rose durum aracı kullanılarak bilgi sistemlerinin nesne yönelimli analizi ve tasarımı - M .: IT Academy, 2000.

6. Gnatush A. CASE teknolojileri: ne, ne zaman, nasıl? // BT yöneticisi - 2004. - No. 16 (4).

7. Zinder E.Z. İş yeniden yapılandırması ve sistem tasarım teknolojileri. Ders Kitabı - M .: Bilgi Teknolojileri Merkezi, 2002.

8. Kalyanov G.N. dava. Yapısal sistem analizi (otomasyon ve uygulama) - M.: Lori, 2003.

9. Korolev K.Z. Bilgi Teknolojisi ve yazılım. ders kitabı M.: DANA, 2003.

10. Mark D.A., McGowan K. Yapısal analiz ve tasarım metodolojisi - M .: MetaTechnology, 2003.

4.2. CASE araçlarının değerlendirilmesi ve seçimi

4.2.1. Genel bilgi

Aşağıda tartışılan değerlendirme ve seçim süreci modeli (Şekil 4.2), değerlendirme ve seçimin en genel durumunu tanımlar ve ayrıca bunlar arasındaki ilişkiyi gösterir. Görüldüğü gibi değerlendirme ve seçim birbirinden bağımsız ya da birlikte yapılabilmekte, bu süreçlerin her biri belirli kriterlerin uygulanmasını gerektirmektedir.

Değerlendirme ve seçim sürecinin, aşağıdakilerden biri veya daha fazlası dahil olmak üzere çeşitli hedefleri olabilir:

  • birkaç CASE aracının değerlendirilmesi ve bunlardan bir veya daha fazlasının seçilmesi;
  • bir veya daha fazla CASE aracının değerlendirilmesi ve sonuçların daha sonra kullanılmak üzere saklanması;
  • önceki değerlendirmelerin sonuçlarını kullanarak bir veya daha fazla CASE aracının seçilmesi.


Pirinç. 4.2. Değerlendirme ve seçim süreci modeli

Şekilden de görülebileceği gibi, değerlendirme süreci için girdi bilgileri şöyledir:

  • kullanıcı ihtiyaçlarının tanımlanması;
  • projenin hedefleri ve sınırlamaları;
  • mevcut CASE araçlarına ilişkin veriler;
  • değerlendirme sürecinde kullanılan kriterlerin bir listesi.

Değerlendirme sonuçları önceki değerlendirmelerin sonuçlarını içerebilir. Ancak bir önceki değerlendirmede kullanılan kriter setinin mevcut set ile uyumlu olması gerektiği unutulmamalıdır. Sürecin özel uygulaması (değerlendirme ve seçim, gelecekteki seçim için değerlendirme veya önceki değerlendirmelere dayalı seçim) yukarıda sıralanan hedeflere göre belirlenir.

Süreç öğeleri şunları içerir:

  • süreç boyunca iyileştirilebilecek hedefler, varsayımlar ve kısıtlamalar;
  • CASE araçları için kullanıcıların nicel ve nitel gereksinimlerini yansıtan kullanıcı ihtiyaçları;
  • değerlendirmenin yapıldığı ve seçim kararının verildiği bir dizi parametreyi tanımlayan kriterler;
  • bir veya daha fazla aracın değerlendirilmesinin resmileştirilmiş sonuçları;
  • önerilen bir karar (genellikle bir seçim kararı veya ileri değerlendirme).

Değerlendirme ve/veya seçim süreci, yalnızca bir kişi, grup veya kuruluş kendisi için özel ihtiyaçları tam olarak tanımladığında ve bunları belirli bir konu alanında niceliksel ve niteliksel gereksinimler şeklinde resmileştirdiğinde başlatılabilir. Bundan sonra "kullanıcı gereksinimleri" terimi, sadece bu tür resmileştirilmiş gereksinimler anlamına gelir.

Kullanıcı, belirli eylem planını ve gerekli yinelemelerle karar vermeyi belirlemelidir. Örneğin, süreç, sıralı geçişi ve daha ayrıntılı değerlendirme için aday alt kümelerinin seçimi ile bir karar ağacı olarak temsil edilebilir. Eylem dizisinin açıklaması, aralarındaki veri akışını tanımlamalıdır.

Ölçüt listesi tanımı, kullanıcı gereksinimlerine dayalıdır ve şunları içerir:

  • aşağıdaki listeden kullanım kriterlerinin seçimi;
  • ek kriterlerin tanımı;
  • her bir kriterin kapsamının tanımlanması (değerlendirme, seçim veya her ikisi);
  • her bir değerlendirme kriteri için bir veya daha fazla metrik tanımlama;
  • her seçim kriterine bir ağırlık atama.

4.2.2. Değerlendirme süreci

Değerlendirme sürecinin amacı, sonraki seçim için CASE araçlarının işlevselliğini ve kalitesini belirlemektir. Değerlendirme, belirli kriterlere göre gerçekleştirilir ve sonuçları, her çare için hem nesnel hem de öznel verileri içerir.

Değerlendirme süreci aşağıdaki adımları içerir:

  • değerlendirmenin amacı ve kapsamı hakkında bilgiler de dahil olmak üzere, değerlendirmenin amacının beyanı;
  • görev tanımından kaynaklanan değerlendirme kriterlerinin tanımı;
  • aday listesini inceleyerek ve belirli fonlarla ilgili bilgileri analiz ederek aday fonların belirlenmesi;
  • aday fonların seçilen kriterler bağlamında değerlendirilmesi. Bunun için gerekli veriler, araçların kendilerini ve belgelerini analiz ederek, kullanıcılarla görüşerek, demo sürümleriyle çalışarak, test senaryolarını çalıştırarak, araçlarla deneyler yaparak ve önceki değerlendirmelerin sonuçlarını analiz ederek elde edilebilir;
  • değerlendirme sonuçlarına ilişkin bir raporun hazırlanması.

Değerlendirme sürecindeki en önemli kriterlerden biri, aday araçların her birinin halihazırda faaliyette olan veya organizasyonda kullanılması planlanan diğer araçlarla olası entegrasyonu olabilir.

Değerlendirmenin kapsamı, gereken ayrıntı düzeyini, gereken kaynakları ve sonuçların uygulanabilirliğini ortaya koymalıdır. Örneğin, değerlendirme bir veya daha fazla spesifik CASE tesisi üzerinde gerçekleştirilmelidir; Yazılım oluşturmak ve sürdürmek için bir veya daha fazla belirli süreci destekleyen CASE araçları veya bir veya daha fazla projeyi veya proje türünü destekleyen CASE araçları.

CASE araçlarının listesi - olası adaylar çeşitli kaynaklardan oluşturulmuştur: yazılım pazarı incelemeleri, satıcı bilgileri, CASE araçları incelemeleri ve diğer benzer yayınlar.

Bir sonraki adım, CASE tesisleri hakkında bilgi almak veya bunları kendileri almak veya her ikisini birden yapmaktır. Bu bilgiler, bağımsız yargılardan, CASE aracı satıcılarından gelen iletişimlerden ve raporlardan, satıcılar tarafından CASE aracı gösterilerinden ve doğrudan gerçek kullanıcılardan alınan bilgilerden oluşabilir. CASE araçları satın alınarak, bir değerlendirme kopyası olarak veya başka yollarla elde edilebilir.

İlgili verilerin değerlendirilmesi ve toplanması aşağıdaki şekillerde gerçekleştirilebilir:

  • CASE araçlarının ve satıcı belgelerinin analizi;
  • gerçek kullanıcıların anketi;
  • bu CASE araçlarını kullanan projelerin sonuçlarının analizi;
  • gösterileri ve oy kullanan göstericileri izlemek;
  • test senaryolarının yürütülmesi;
  • CASE araçlarının pilot projelerde uygulanması;
  • Önceki değerlendirmelerden elde edilen mevcut sonuçların analizi.

Hem nesnel hem de öznel kriterler vardır. Belirli bir kritere göre değerlendirme sonuçları ikili olabilir, belirli bir sayısal aralıkta olabilir, basit bir sayısal değer olabilir veya başka bir biçimde olabilir.

Objektif kriterler için değerlendirme, tekrarlanabilir bir prosedürle yapılmalıdır, böylece değerlendirmeyi yapan herhangi bir kişi aynı sonuçları elde edebilir. Test senaryoları kullanılıyorsa, kümeleri önceden tanımlanmalı, birleştirilmeli ve belgelenmelidir.

Sübjektif kriterlere göre, bir CASE aracı aynı kriterler kullanılarak bir grup uzman tarafından değerlendirilmelidir. Bireylerin veya ekiplerin gerekli uzmanlık düzeyi önceden belirlenmelidir.

Değerlendirmenin sonuçları standart bir şekilde (sonraki kullanımı kolaylaştırmak için) belgelenmeli ve gerekirse doğrulanmalıdır.

Değerlendirme raporu aşağıdaki bilgileri içermelidir:

  • giriiş. Sürece genel bir bakış ve ana çıktıların listesi;
  • arka plan. Değerlendirmenin amacı ve istenen sonuçlar, değerlendirmenin yürütüldüğü süre, değerlendirmeyi yapan uzmanların rollerinin tanımı ve ilgili deneyimleri;
  • değerlendirme yaklaşımı. Elde edilen CASE araçları, değerlendirmenin bağlamını ve kapsamını tanımlayan bilgiler ve tüm varsayımlar ve sınırlamalar dahil olmak üzere genel yaklaşımın açıklaması;
  • CASE araçları hakkında bilgi . Aşağıdakileri içermelidir: 1) CASE aracının adı; 2) CASE aracı sürümü; 3) iletişim adresi ve telefon numarası dahil olmak üzere tedarikçinin ayrıntıları; 4) teknik araçların konfigürasyonu; 5) maliyet verileri; 6) CASE aracının açıklaması, bu araç tarafından desteklenen yazılım oluşturma ve bakım süreçleri, CASE aracı yazılım ortamı (özellikle desteklenen programlama dilleri, işletim sistemleri, veritabanı uyumluluğu), CASE aracı işlevleri, giriş/çıkış verileri ve alan uygulamaları;
  • değerlendirme adımları. Değerlendirme sürecine dahil olan belirli faaliyetler, hem değerlendirmenin kapsamını ve derinliğini anlamak hem de gerekirse tekrarlamak için gerekli ayrıntı düzeyinde tanımlanmalıdır;
  • somut sonuçlar . Değerlendirme sonuçları, değerlendirme kriterleri açısından sunulmalıdır. Raporun bir dizi CASE aracını kapsadığı veya bu değerlendirmenin sonuçlarının diğer değerlendirmelerden alınan benzer sonuçlarla karşılaştırılacağı durumlarda, bu tür karşılaştırmaları kolaylaştırmak için sonuçların sunumuna özel dikkat gösterilmelidir. Subjektif sonuçlar objektif olanlardan ayrılmalı ve gerekli açıklamalarla birlikte sunulmalıdır;
  • sonuçlar ve sonuçlar;
  • uygulamalar.Değerlendirme görevinin formülasyonu ve güncellenmiş bir kriter listesi.

4.2.3. Seçim süreci

Değerlendirme ve seçim süreçleri birbiriyle yakından ilişkilidir. Değerlendirmenin sonuçlarına göre, seçim hedefleri ve/veya seçim kriterleri ve bunların ağırlıklarının değiştirilmesi gerekebilir. Bu gibi durumlarda yeniden değerlendirme gerekebilir. Nihai değerlendirme sonuçları analiz edildiğinde ve bunlara seçim kriterleri uygulandığında, bir CASE aracının veya bir CASE araçları setinin satın alınması önerilebilir. Bir alternatif, yeterli CASE araçlarının olmaması olabilir; bu durumda yeni bir CASE aracı geliştirmeniz, mevcut bir aracı değiştirmeniz veya uygulamadan vazgeçmeniz önerilir.

Seçim süreci, değerlendirme süreci ile yakından ilgilidir ve aşağıdaki adımları içerir:

  • hedefler, varsayımlar ve kısıtlamalar dahil olmak üzere seçim hedeflerinin formülasyonu;
  • kriterlerin belirlenmesi ve sıralanması, aday remedilerin belirlenmesi, gerekli verilerin toplanması ve en iyi performans gösteren remedilerin belirlenmesi için sıralanan kriterlerin değerlendirme sonuçlarına uygulanması dahil olmak üzere gerekli tüm seçim eylemlerinin gerçekleştirilmesi. Birçok kullanıcı için önemli bir seçim kriteri, CASE aracının mevcut ortamla entegrasyonudur;
  • benzer göstergelere sahip araçları seçmek (veya reddetmek) için gerekli sayıda yinelemenin gerçekleştirilmesi;
  • seçim sonuçlarına ilişkin bir raporun hazırlanması.

Seçim sürecinde iki olası sonuç vardır:

  • belirli bir CASE aracının seçilmesine yönelik öneriler;
  • değerlendirme süreci için ek bilgi talebi.

Seçim ölçeği, gerekli detay seviyesini, gerekli kaynakları, programı ve beklenen sonuçları belirlemelidir. Aşağıdakiler de dahil olmak üzere ölçeği belirlemek için kullanılabilecek bir dizi parametre vardır:

  • ön seçimin kullanılması (örneğin, yalnızca belirli bir platformda çalışan fonların seçilmesi);
  • önceden elde edilen değerlendirme sonuçlarını, dış kaynaklardan alınan değerlendirme sonuçlarını veya her ikisinin bir kombinasyonunu kullanarak;

Önceki değerlendirmelerin farklı ölçüt grupları kullanılarak veya belirli ölçütler kullanılarak ancak farklı şekillerde gerçekleştirilmesi durumunda, değerlendirmelerin sonuçları tutarlı bir şekilde sunulmalıdır. Bu adım tamamlandıktan sonra, her bir CASE aracının puanı tek bir ölçüt grubu altında sunulmalı ve diğer puanlarla doğrudan karşılaştırılabilir olmalıdır.

Seçim için yaygın olarak kullanılan algoritmalar, ölçeğe veya sıralamaya dayalı olabilir. Ölçeğe dayalı algoritmalar, her bir CASE tesisi için her bir kriterin ağırlığını değeriyle çarparak (ölçeği dikkate alarak) ve tüm ürünleri toplayarak tek bir değer hesaplar. En yüksek puana sahip CASE aracı birinci sırayı alır. Dereceye dayalı algoritmalar, aday CASE araçlarının, belirli bir ölçekteki kriterlerin değerlerine göre bireysel kriterlere veya kriter gruplarına göre sıralamasını kullanır. Ardından bir öncekine benzer şekilde ranklar bir araya getirilerek toplam rank değerleri hesaplanır.

Seçim sonuçları analiz edilirken seçim sürecinin tamamlandığı varsayılır, CASE aracı seçilir ve kullanılması önerilir. Bununla birlikte, anahtar kriterlerin değerlerinin CASE adaylarının özelliklerinin değerlerindeki farklılıklara bağımlılık derecesini belirlemek için daha kesin bir analiz gerekebilir. Böyle bir analiz, CASE-ortalama sıralamasının sonucunun, kriter ağırlık katsayılarının optimal seçimine ne ölçüde bağlı olduğunu belirlemeyi mümkün kılacaktır. Çok benzer kriter değerlerine veya sıralarına sahip CASE araçları arasındaki önemli farklılıkları belirlemek için de kullanılabilir.

CASE araçlarından hiçbiri minimum kriterleri karşılamıyorsa, diğer aday CASE araçları için seçim (belki puanla birlikte) tekrar edilebilir.

En çok tercih edilen adaylar arasındaki farklar anlamlı değilse, ek veya farklı kriterler kullanılarak yeniden seçim yapılarak (muhtemelen bir puanla birlikte) ek bilgi elde edilebilir.

Seçim önerileri kesinlikle gerekçelendirilmelidir. Yeterli CASE araçlarının yokluğunda, yukarıda belirtildiği gibi, yeni bir CASE aracı geliştirmeniz, mevcut olanı değiştirmeniz veya uygulamadan vazgeçmeniz önerilir.

4.2.4. Değerlendirme ve seçim kriterleri

Kriterler, değerlendirme ve seçim süreçleri için temel oluşturur ve aşağıdakiler de dahil olmak üzere pek çok biçimde olabilir:

  • gereken bellek miktarı gibi çok çeşitli değerlerde sayısal ölçümler;
  • sınırlı bir değer aralığındaki sayısal ölçümler, örneğin, 1'den 5'e kadar puanlarla ifade edilen öğrenme kolaylığı;
  • Postscript formatında dokümantasyon oluşturma yeteneği gibi ikili ölçümler (doğru/yanlış, evet/hayır);
  • CASE tesisinin desteklendiği platformlar gibi bir veya daha fazla sonlu değer kümesinin alabileceği önlemler.

Tipik bir değerlendirme ve/veya seçim süreci, bir dizi farklı türde kriter kullanabilir.

Kriter setinin yapısı Şekil 4.3'te gösterilmiştir. Her kriter, belirli bir sürecin özellikleri dikkate alınarak bir uzman tarafından seçilmeli ve uyarlanmalıdır. Çoğu durumda, aşağıda açıklanan birçok kriterden yalnızca bazıları kabul edilebilir ve ek kriterler de eklenir. Kullanılacak kriter setinin seçilmesi ve rafine edilmesi, değerlendirme ve/veya seçim sürecinde kritik bir adımdır.

fonksiyonel özellikler

Birinci sınıfın kriterleri, CASE aracının işlevsel özelliklerini belirlemeye yöneliktir. Sırayla, bir dizi gruba ve alt gruba ayrılırlar.

  1. Çalışma ortamı:
    1. Proje ortamı:
  • yaşam döngüsü süreçleri için destek . CASE aracının desteklediği yaşam döngüsü süreçleri kümesini tanımlar. Bu tür süreçlere örnek olarak gereksinim analizi, tasarım, uygulama, test ve değerlendirme, bakım, kalite güvencesi, konfigürasyon yönetimi ve proje yönetimi verilebilir ve bunlar kullanıcı tarafından benimsenen yaşam döngüsü modeline bağlıdır.
  • uygulama alanı Örnekler, işlem işleme sistemleri, gerçek zamanlı sistemler, bilgi sistemleri vb.
  • desteklenen uygulama boyutu . Kod satırı sayısı, iç içe geçme düzeyleri, veritabanı boyutu, veri öğesi sayısı, yapılandırma yönetimi nesnesi sayısı gibi değerler üzerinde sınırlar tanımlar.
  • Yazılım Donanım:
    • gerekli teknik araçlar . İşlemci türü, RAM miktarı ve disk belleği dahil olmak üzere CASE aracının çalışması için gerekli ekipman.
    • desteklenen teknik araçlar . G/Ç aygıtları gibi CASE aracı tarafından kullanılabilen donanım öğeleri.
    • gerekli yazılım. İşletim sistemleri ve grafik kabuklar dahil olmak üzere CASE aracının çalışması için gerekli yazılımlar.
    • desteklenen yazılım . CASE aracı tarafından kullanılabilen yazılım ürünleri.



    Pirinç. 4.3. Kriter seti yapısı

      1. Teknolojik ortam:
    • proses ortamı standartlarına uygunluk . Bu tür standartlar, dil, veri tabanı, havuz, iletişim, grafik kullanıcı arayüzü, dokümantasyon, geliştirme, konfigürasyon yönetimi, güvenlik, iletişim standartları ve veri, kontrol ve kullanıcı arayüzü entegrasyonu ile ilgilidir.
    • diğer araçlarla uyumluluk . Doğrudan veri alışverişi dahil olmak üzere diğer araçlarla etkileşime girme yeteneği (bu tür araçlara örnek olarak kelime işlemciler, veritabanları ve diğer CASE araçları verilebilir). Bir depoyu veya bir kısmını başka yollarla işlemek için standart bir biçime dönüştürme yeteneği.
    • desteklenen metodoloji . CASE aracı tarafından desteklenen yöntem ve teknikler kümesi. Örnekler, yapısal veya nesne yönelimli analiz ve tasarımdır.
    • desteklenen diller . CASE aracı tarafından kullanılan tüm diller. Bu tür dillere örnek olarak programlama dilleri (Cobol, Ada, C), veritabanı ve sorgulama dilleri (DDL, SQL), grafik dilleri (Postscript, HPGL), proje gereksinimleri belirleme dilleri ve işletim sistemi arayüzleri gösterilebilir. (iş kontrol dilleri).
  • Yaşam döngüsü aşamalarına odaklanan özellikler:
    1. Modelleme:
      Bu kriterler, yazılım gereksinimlerini belirlemek ve bunları bir projeye dönüştürmek için gerekli işlevleri gerçekleştirme yeteneğini belirler:
    • diyagram oluşturma . Kullanıcının ilgi alanına giren çeşitli türlerde diyagramlar oluşturma ve düzenleme yeteneği. En yaygın grafik türleri Bölüm 2'de açıklanmıştır.
    • grafik analiz . Grafik nesneleri analiz etme ve tasarım bilgilerini grafiksel bir sunumda saklama ve sunma becerisi. Çoğu durumda, grafik analizörler, grafik oluşturma araçlarıyla entegre edilmiştir.
    • gereksinim belirtimlerinin ve tasarım belirtimlerinin girilmesi ve düzenlenmesi . Bu tür spesifikasyonlar, fonksiyonların, verilerin, arayüzlerin, yapının, kalitenin, performansın, tesislerin, ortamın, maliyetlerin ve programların açıklamalarını içerir.
    • gereksinim belirtimi ve tasarım belirtim dili . Resmi bir dil kullanarak spesifikasyonları içe aktarma, dışa aktarma ve düzenleme yeteneği.
    • veri modelleme . Sistem veri öğelerini ve bunların ilişkilerini açıklayan bilgileri girme ve düzenleme yeteneği.
    • süreç modelleme . Sistem süreçlerini ve bunların ilişkilerini açıklayan bilgileri girme ve düzenleme yeteneği.
    • yazılım mimarisi tasarımı . Yazılımın mantıksal yapısının tasarlanması - modüllerin yapısı, arayüzler vb.
    • simülasyon modelleme . Ön uç ve performans (ör. yanıt süresi, kaynak kullanımı ve verim) dahil olmak üzere gereksinimlere ve/veya tasarım özelliklerine dayalı olarak sistem operasyonunun çeşitli yönlerini dinamik olarak modelleme yeteneği.
    • prototipleme Gereksinim belirtimlerine ve/veya tasarım belirtimlerine dayalı olarak tüm sistemin veya tek tek bileşenlerinin bir ön sürümünü tasarlama ve oluşturma yeteneği. Prototipleme esas olarak harici kullanıcı arayüzü ile ilgilidir ve kullanıcıların doğrudan katılımıyla gerçekleştirilir.
    • ekran formu oluşturma . Gereksinim özelliklerine ve/veya tasarım özelliklerine göre ekran formları oluşturma yeteneği.
    • izleme yeteneği . Gereksinimlerin belirlenmesinden nihai sonuçlara kadar sistemin işleyişinin uçtan uca analizi olasılığı (BS için işlevsel ve diğer dış gereksinimler, teknik çözümler ve tasarım sonuçları arasındaki yazışmaların ve ilişkilerin kurulması ve izlenmesi). İleri izleme (tüm gereksinimlerin dikkate alınıp alınmadığının kontrol edilmesi) ve geriye doğru izleme (herhangi bir dış gereksinimle ilgili olmayan tasarım çözümlerinin araştırılması).
    • tasarım özelliklerinin sözdizimsel ve anlamsal kontrolü. Diyagramların sözdizimini ve öğelerinin türlerini kontrol etme, fonksiyonların ayrışmasını kontrol etme, tamlık ve tutarlılık için spesifikasyonları kontrol etme.
    • diğer analiz türleri . Spesifik ek analizler, algoritmaları, veri akışlarını, veri normalleştirmeyi, veri kullanımını, kullanıcı arayüzünü içerebilir.
    • raporların otomatik tasarımı.
  • Uygulama:
    Uygulama, sistemin yürütülebilir öğelerinin (program kodları) oluşturulması veya mevcut bir sistemin değiştirilmesi ile ilgili işlevleri etkiler. Aşağıda listelenen kriterlerin çoğu dile özgüdür ve aşağıdakileri içerir:
    • sözdizimsel kontrollü düzenleme . Eşzamanlı sözdizimsel kontrol ile bir veya daha fazla dilde kaynak kodlarını girme ve düzenleme yeteneği.
    • kod üretimi. Tasarım özelliklerine göre bir veya daha fazla dilde kod üretebilme. Üretilen kod türleri, normal program kodunu, veritabanı şemasını, sorguları, ekranları/menüleri içerebilir.
    • kodu derlemek.
    • kaynak kodu dönüştürme . Kodu bir dilden diğerine dönüştürme yeteneği.
    • Güvenilirlik analizi . Hata sayısı vb. gibi yazılım güvenilirlik parametrelerini ölçme yeteneği.
    • tersine mühendislik . Mevcut kaynak kodlarını analiz etme ve bunlara dayalı tasarım özellikleri oluşturma becerisi.
    • kaynak kodu yeniden yapılandırma . Mevcut kaynak kodunun biçimini ve/veya yapısını değiştirme yeteneği.
    • kaynak kodu analizi . Bu tür analiz örnekleri, kod boyutu belirleme, karmaşıklık puanı hesaplama, çapraz referans oluşturma ve standart kontrolüdür.
    • hata ayıklama. Tipik hata ayıklama özellikleri, programları izleme, darboğazları ve en sık kullanılan kod parçalarını vb. vurgulamadır.
  • Test yapmak:
    Test kriterleri aşağıdakileri içerir:
    • test açıklaması. Tipik yetenekler, test verileri, test algoritmaları, gerekli sonuçlar vb. oluşturmayı içerir.
    • operatör eylemlerini sabitleme ve tekrarlama . Operatör tarafından klavye, fare vb. kullanılarak girilen verileri yakalama, bunları düzenleme ve test durumlarında çoğaltma yeteneği.
    • test durumlarının otomatik olarak başlatılması.
    • gerileme testi . Sistem ve/veya ortamdaki farklılıkları belirlemek için daha önce gerçekleştirilen testleri tekrarlama ve değiştirme yeteneği.
    • test sonuçlarının otomatik analizi . Tipik özellikler, beklenen ve gerçek sonuçların karşılaştırılmasını, dosya karşılaştırmasını, sonuçların istatistiksel analizini vb. içerir.
    • test kapsamı analizi . Kaynak kodu kontrol araçları ve test kapsamı analizi ile donatılmıştır. Özellikle operatörlere yapılan çağrılar, prosedürler ve değişkenler kontrol edilir.
    • performans analizi . Programların performansını analiz edebilme. Analiz edilen performans parametreleri CPU kullanımını, bellek kullanımını, belirli veri öğelerine ve/veya kod bölümlerine erişimi, zamanlamayı vb. içerebilir.
    • test sürecinde istisnai durumların analizi.
    • ortamın dinamik modellemesi. Özellikle, simüle edilmiş sistem girdilerini otomatik olarak oluşturma yeteneği.
  • Genel Fonksiyonlar:
    Aşağıdaki kriterler, yaşam döngüsünün tüm aşamalarını kapsayan CASE araçlarının işlevlerini tanımlar. Tüm bu işlevler depo aracılığıyla desteklenir.
    1. Belgeler:
    • metinleri ve grafikleri düzenleme . Metin ve grafik biçiminde veri girme ve düzenleme yeteneği.
    • formlarla düzenleme . Kullanıcı tanımlı formları destekleme, formlara göre veri girme ve düzenleme yeteneği.
    • yayınlama yetenekleri.
    • köprü metni işlevleri ve biçimleri için destek.
    • dokümantasyon standartlarına uygunluk.
    • Veri havuzundan verilerin otomatik olarak çıkarılması ve kullanıcı özelliklerine göre belgelerin oluşturulması.
  • Konfigürasyon yönetimi:
    • erişim ve değişiklik kontrolü . Veri öğelerine fiziksel düzeyde erişimi kontrol etme ve kontrolü değiştirme yeteneği. Erişim kontrolü, bileşenlere erişim haklarını belirleme, değişiklik için veri öğelerini çıkarma, değişiklik sırasında bunlara erişimi engelleme ve depoya geri yerleştirme yeteneğini içerir.
    • değişiklik takibi . Geliştirme veya bakım sırasında sistemde yapılan tüm değişikliklerin kaydedilmesi ve günlüğe kaydedilmesi.
    • sürüm kontrolü . Sistemin ve tüm paylaşılan bileşenlerinin sürüm verilerinin bakımı ve kontrolü.
    • yapılandırma yönetimi nesnelerinin durumunun muhasebeleştirilmesi . Çeşitli yapılandırma yönetimi nesnelerinin ardışık tüm sürümleri, içeriği ve durumu hakkında rapor verme yeteneği.
    • sürümlerin oluşturulması ve modifikasyonlar . Sürümleri ve değişiklikleri oluşturmak için gerekli eylem dizisinin kullanıcı açıklaması ve bu eylemlerin otomatik olarak yürütülmesi için destek.
    • arşivleme. Veri öğelerini daha sonra kullanmak üzere otomatik olarak arşivleme yeteneği.
  • Proje Yönetimi:
    • iş ve kaynak yönetimi . IS tasarım sürecinin görevlerin yapısı ve icracıların atanması, uygulama sırası, projenin bireysel aşamalarının tamamlanması ve bir bütün olarak proje açısından kontrolü ve yönetimi. Planlanan verileri, gerçek verileri ve bunların analizlerini destekleyebilme. Tipik veriler programları (takvimi, çalışma saatlerini, tatilleri vb. hesaba katarak), bilgisayar kaynaklarını, personel dağılımını, bütçeyi vb. içerir.
    • seviye. Kullanıcılar tarafından girilen maliyetleri, programı ve diğer tasarım parametrelerini değerlendirebilme.
    • test prosedürü yönetimi . Planlanan prosedürlerin zamanlamasını yönetme, test sonuçlarını sabitleme ve kaydetme, raporlar oluşturma vb. gibi prosedürlerin ve test programının yönetimine yönelik destek.
    • kalite kontrol . İlgili verilerin girilmesi, analiz edilmesi ve raporların oluşturulması.
    • düzeltici eylemler . Sorun raporlama dahil olmak üzere düzeltici eylem yönetimi desteği.

    4.2.4.1. Güvenilirlik

    • depo yönetimi. Tasarım verilerinin bütünlüğünü kontrol edin ve sağlayın.
    • otomatik artıklık (sağlayıcı tanımlı veya kullanıcı planlı).
    • emniyet. Yetkisiz erişime karşı koruma.
    • hata işleme. Sistemin işleyişindeki hataların tespiti, kullanıcıya bildirilmesi, kesinti anında incelikle kapatılması veya durumun kaydedilmesi.
    • Kritik uygulamalarda hata analizi.

    4.2.4.2. Kullanım kolaylığı

    • kullanıcı arayüzünün rahatlığı. Sık kullanılan ekran öğelerinin, veri giriş yöntemlerinin vb. uygun düzeni ve sunumu.
    • yerelleştirme (belirli bir ülkenin gereksinimlerine göre).
    • öğrenme kolaylığı. Fonların geliştirilmesi için emek ve zaman maliyetleri.
    • belirli kullanıcı gereksinimlerine uyarlanabilirlik. Farklı alfabelere, metin ve grafik sunum modlarına (soldan sağa, yukarıdan aşağıya), farklı tarih formatlarına, giriş/çıkış yöntemlerine (ekran formları ve formatları), metodolojideki değişikliklere (grafik gösterimlerdeki değişiklikler, kurallar) uyarlanabilirlik , önceden tanımlanmış nesnelerin özellikleri ve bileşimi) vb.
    • dokümantasyonun kalitesi (tamlık, anlaşılabilirlik, okunabilirlik, kullanışlılık, vb.).
    • eğitim materyallerinin mevcudiyeti ve kalitesi. Bunlar, bilgisayar tabanlı öğrenme materyallerini, eğitimleri, kursları içerebilir.
    • bilgi düzeyi gereksinimleri. CASE araçlarını etkili bir şekilde kullanmak için gereken nitelikler ve deneyim.
    • CASE aracıyla çalışma kolaylığı (hem yeni başlayanlar hem de deneyimli kullanıcılar için).
    • kullanıcı arayüzünün birleştirilmesi (bu organizasyonda kullanılan diğer araçlarla ilgili olarak).
    • çevrimiçi ipuçları (tamlık ve kalite).
    • teşhis kalitesi (kullanıcı için teşhis mesajlarının anlaşılırlığı ve kullanışlılığı).
    • kullanıcı eylemlerine izin verilen yanıt süresi (ortama bağlı olarak).
    • Sürümleri yüklemek ve güncellemek kolaydır.

    4.2.4.3. Yeterlik

    • teknik gereksinimler. Kabul edilebilir bir performans düzeyi sağlayan, harici ve RAM'in optimum boyutu, işlemcinin tipi ve performansı için gereksinimler.
    • iş yükü verimliliği. Kullanıcının işinin yoğunluğuna bağlı olarak (örneğin, belirli işlevleri gerçekleştirmek için gereken tuş vuruşlarının veya fare düğmelerinin sayısı) bir CASE aracının işlevlerini ne kadar verimli bir şekilde yerine getirdiği.
    • verim. CASE aracının belirli görevleri gerçekleştirmek için harcadığı süre (örneğin, sorgu yanıt süresi, 100.000 satırlık kodun ayrıştırma süresi). Bazı durumlarda, performans değerlendirme verileri dış kaynaklardan elde edilebilir.

    4.2.4.4. sürdürülebilirlik

    • satıcının destek düzeyi (sorun çözme hızı, yeni sürümlerin teslimi, ek özelliklerin sağlanması).
    • güncellemelerin izlenebilirliği (yeni sürümler ile mevcut sürümler arasındaki farkları öğrenme kolaylığı).
    • güncelleme uyumluluğu (örneğin, giriş veya çıkış uyumluluğu dahil olmak üzere yeni sürümlerin mevcut sürümlerle uyumluluğu).
    • Nihai ürünün sürdürülebilirliği (yazılım ve belgelerde değişiklik yapma kolaylığı).

    4.2.4.5. taşınabilirlik

    • işletim sistemi sürümleriyle uyumluluk (aynı işletim sisteminin farklı sürümlerinin bulunduğu bir ortamda çalışabilme, CASE aracını yeni işletim sistemi sürümleriyle çalışacak şekilde değiştirme kolaylığı).
    • CASE aracının farklı sürümleri arasında verilerin taşınabilirliği.
    • taşınabilirlik standartları Bu tür standartlar dokümantasyon, iletişim ve kullanıcı arabirimi, pencere arabirimi, programlama dilleri, sorgulama dilleri vb. içerir.

    4.2.4.6. Genel Kriterler

    Aşağıdaki kriterler doğası gereği geneldir ve ISO/IEC 9126: 1991'de verilen kalite göstergeleri grubuna ait değildir.

    • CASE aracı maliyetleri. Satın alma, kurulum, ilk bakım ve eğitim maliyetlerini içerir. Gerekli tüm yapılandırmalar (tek kopya, birden çok kopya, yerel lisans, kurumsal lisans, ağ lisansı dahil) için fiyatlandırmayı göz önünde bulundurun.
    • CASE araçlarının (verimlilik düzeyi, kalite, vb.) kullanıma sunulmasından elde edilen tahmini etki. Böyle bir değerlendirme ekonomik bir analiz gerektirebilir.
    • distribütör profili. Distribütörün yeteneklerinin genel göstergeleri. Bir distribütörün profili, kuruluşunun büyüklüğünü, iş süresinin uzunluğunu, mali durumunu, ek ürünlerin listesini, iş bağlantılarını (özellikle diğer distribütörlerle) içerebilir. bu araç), planlanan geliştirme stratejisi.
    • tedarikçi sertifikası. Özel yazılım kuruluşlarından (SEI ve ISO gibi) alınan sertifikalar, tedarikçinin yazılım oluşturma ve sürdürme niteliklerinin belirli minimum veya iyi tanımlanmış gereksinimleri karşıladığını onaylar. Sertifikasyon gayri resmi olabilir, örneğin tedarikçinin performansının analizine dayalı olabilir.
    • lisans politikası. Mevcut lisanslama seçenekleri, kopyalama hakkı (medya ve belgeler), ikincil kullanım için herhangi bir kısıtlama ve/veya ceza (CASE aracının geliştirilmesinde kullanılan CASE aracının bazı bileşenlerini içeren ürünlerin CASE aracı kullanıcısı tarafından satışı anlamına gelir) ürünler).
    • ihracat kısıtlamaları
    • ürün profili. Kullanım ömrü, satılan kopya sayısı, kullanıcı grubunun varlığı, boyutu ve etkinlik düzeyi, sorun raporlama sistemi, ürün geliştirme programı, uygulama karması, hatalar vb. dahil olmak üzere ürünle ilgili genel bilgiler.
    • tedarikçi desteği. Sağlayıcı tarafından CASE araçlarının kullanıcıları için sağlanan hizmetlerin mevcudiyeti, tepkiselliği ve kalitesi. Bu tür hizmetler arasında telefon hattı, yerel teknik destek, kuruluş içi destek yer alabilir.
    • eğitimin mevcudiyeti ve kalitesi. Eğitim, tedarikçinin tesislerinde, kullanıcının tesislerinde veya başka bir yerde yapılabilir.
    • kullanıcının kuruluşunda CASE araçlarını uygulamak için gereken uyarlamalar. Bir örnek, merkezi bir CASE aracını dağıtılmış bir ortamda tek bir paylaşılan veritabanıyla kullanmanın bir yolunu tanımlamak olabilir.

    4.2.5. CASE araçlarını seçmek için kriterleri tanımlamaya yönelik bir yaklaşım örneği

    CASE araçlarını seçmek için kriterleri tanımlamaya yönelik bir yaklaşım örneği içinde verilmiştir. CASE araçlarının, girişte listelenen özelliklere sahip büyük bir standart IS projesinde kullanılacağı varsayılmaktadır. Genel olarak, belirli bir uygulama için CASE araçlarını seçme stratejisi, sırayla kullanılan tasarım metodolojisini belirleyen gelecekteki IS projesinin (tasarım sürecine dahil olan uzmanların nitelikleri dahil) amaçlarına, gereksinimlerine ve kısıtlamalarına bağlıdır. .

    Belirli araçların seçiminde belirleyici faktörün kullanılan metodoloji ve tasarım teknolojisi olduğu, bunun tersi olmadığı vurgulanmalıdır. Bu bakış açısından, CASE araçlarını metodolojiden ayrı olarak karşılaştırmanın bir anlamı yoktur, çünkü IS prensipte herhangi bir yolla geliştirilebilir.

    Geleneksel olarak, CASE araçlarını seçme sorunu tartışılırken, konu alanını analiz etmek için şu veya bu metodolojinin (E-R, IDEF0, IDEF1X, Gane/Sarson, Yourdon, Barker, vb.) uygulanmasının özelliklerine çok dikkat edildi. Tabii ki, resimsel ve tanımlayıcı araçların zenginliği, stratejik planlama ve analiz aşamalarında konu alanının en eksiksiz ve yeterli modelini oluşturmayı mümkün kılar. Öte yandan, nihai sonuçlar - veritabanları ve uygulamalar hakkında konuşursak, o zaman bazı açıklamaların pratikte bunlara yansımadığı, tamamen bildirimsel kaldığı (çıktıda, her durumda, bir açıklama alacağız) ortaya çıkar. ile bir tablo görünümünde veritabanının asgari set bütünlük kısıtlamaları ve yürütülebilir uygulama kodu, en doğrudan etki alanı modellerinden türetilmeyen ekran formlarını oluşturan). Deneyimli analistler ve tasarımcılar, bu araçta hangi belirli metodolojinin veya çeşitliliğinin uygulandığına bakılmaksızın her zaman istenen sonuca az ya da çok çabayla ulaşacaktır. Bu, elbette, metodolojinin önemli olmadığı anlamına gelmez, aksine, tanımlayıcı araçların yokluğu veya eksikliği, proje üzerindeki çalışmayı en başından önemli ölçüde engelleyebilir. Bununla birlikte, genellikle başka kriterler öne çıkar ve bunlara uyulmaması çok daha büyük zorluklara yol açabilir.

    Alt bölüm 1.3'te belirtildiği gibi, tasarım teknolojisi, yaşam döngüsünün tüm aşamalarında gerçekleştirilen süreçlerin otomasyonunu sağlayan bir dizi koordineli CASE aracıyla desteklenmelidir. Farklı üreticilerin bileşenlerinden gerekli donanım platformu oluşturulabilirse, her biri kendi sınıfında dünya liderlerinden biri olan farklı araçları da aynı kolaylıkla seçip birleştirebileceği izlenimi edinilebilir. Bununla birlikte, şu anda araçlar için, ekipmandan farklı olarak, nihai ürünlerin (programlar, veritabanları ve bunların arayüzleri) ana özellikleri için uluslararası standartlar yoktur. Projenin bileşenlerinin tek bir ürüne entegre edilmesi gerektiğinden, bu nedenle, prensipte - aynı sınıf içinde bile - farklı metodolojilere yönlendirilebilen herhangi bir aracı değil, yalnızca eşlenik araçları dikkate almak mantıklıdır; aynı zamanda CASE araçları kompleksinin bir parçası olarak en azından benzer metodolojileri destekleyen araçları seçmek gerekir.

    Yukarıda listelenen hususlara dayanarak, aşağıdaki kriterler CASE araçlarının seçiminde ana kriter olarak kabul edilir:

    1. IS'nin tüm yaşam döngüsü için destek, gelişiminin evrimini sağlamak

    IS'nin tüm yaşam döngüsü, aşağıdaki özellikler dikkate alınarak Bölüm 3.2'de listelenen bir dizi araçla desteklenmelidir:

    • coğrafi olarak dağılmış uzman grupları tarafından çeşitli araçlar kullanılarak (entegrasyon, test etme ve hata ayıklama dahil) modellerin, tasarım spesifikasyonlarının ve uygulamalarının geliştirilmesinin kolektif doğası;
    • standart bir projeyi çeşitli sistem ve teknik platformlara (donanım, işletim sistemleri ve DBMS) ve uygulama nesnelerinin organizasyonel ve ekonomik özelliklerine uyarlama ihtiyacı;
    • mevcut gelişmelerle entegrasyon ihtiyacı (uygulamanın yeniden yapılandırılması ve veritabanı dönüştürme dahil). Mevcut IS için sağlanmalıdır yumuşak bir geçiş eski operasyonel ortamdan yenisine minimum değişiklikle ve operasyonel veritabanları ve yeni bir sistemin oluşturulması için çalışmaya başlamadan önce uygulanan uygulamalar için destek.
  • Projenin bütünlüğünün sağlanması ve durumunun izlenmesi
  • Bu gereklilik, IS'nin oluşturulması, sürdürülmesi ve geliştirilmesi için tek bir teknolojik ortamın yanı sıra deponun bütünlüğü anlamına gelir. Tek bir teknolojik ortam, IS modellerini desteklemek için tek bir CASE aracının kullanılması yoluyla ve ayrıca ilgili araçların geliştiricileri tarafından onaylanmış ve desteklenen bireysel araçlar arasında yazılım ve teknolojik arayüzlerin mevcudiyeti yoluyla sağlanmalıdır. Özellikle, CASE araçları ile uygulama geliştirme araçları arasındaki arabirim iki ana işlevi yerine getirmelidir: a) tek bir ortam içinde CASE aracı tarafından uygulanan uygulama mantığının açıklamasından bir kullanıcı arabiriminin (ekran formları) geliştirilmesine doğrudan geçiş; b) veritabanının açıklamasının CASE aracının deposundan uygulama geliştirme aracının deposuna aktarılması ve tersi. Projeyle ilgili tüm bilgiler, projenin tutarlılığını, tutarlılığını, eksiksizliğini ve minimum fazlalığını ve ayrıca düzenleme işlemlerinin doğruluğunu korurken tasarım veritabanına otomatik olarak yerleştirilmelidir. Bu, depoyu güncelleme olasılığını ortadan kaldırarak veya önemli ölçüde sınırlandırarak elde edilebilir. farklı araçlar. CASE aracı çerçevesinde, diyagram ayrıştırmalarının uygunluk kontrolünün yanı sıra çeşitli tipteki diyagramların (örneğin, veri akış diyagramları ve ER diyagramları) uygunluk kontrolü sağlanmalıdır.

    Geliştiricilerin ayrılığı ve büyük bir projenin zaman aralığı bağlamında bütünlük gerekliliğine uyulmaması, durumu üzerinde kontrol kaybı anlamına gelebilir.

    1. Yazılım ve donanım platformundan ve DBMS'den bağımsızlık

    Gereksinim, IS'nin çalışma ortamının heterojenliği tarafından belirlenir. Bu bağımsızlığın iki bileşeni olabilir: geliştirme ortamından bağımsız olma ve uygulama işletim ortamından bağımsız olma. Çeşitli platformlar için CASE araçlarının uyumlu sürümlerinin ve ilgili ağ protokollerinin, işlem yöneticilerinin ve DBMS'nin sürücülerinin bulunmasıyla sağlanır.

    1. Eşzamanlı geliştirme ekipleri için destek

    Geliştirilen CASE araçları, geliştirme personelinin yetkilerini ayırma ve bireysel çalışmaları ortak bir projede birleştirme yeteneğine sahip olmalıdır. Veritabanı tasarımcılarının ve uygulama geliştiricilerinin eşzamanlı (belirli bir ağ yapılandırmasında) çalışması sağlanmalıdır (böyle bir durumda, uygulama geliştiricileri, tasarımının CASE araçları tarafından tamamen tamamlanmasını beklemeden veritabanıyla çalışmaya başlayabilir). Aynı zamanda, tüm uzman gruplarına yeterli araçlar sağlanmalı ve çeşitli geliştiriciler tarafından projede yapılan değişiklikler tutarlı ve doğru olmalıdır. Her geliştirici, paylaşılan havuzun bir parçası veya kopyası olan kendi kişisel deposuyla çalışabilmelidir. Geliştiriciler tarafından yapılan tüm değişiklikler, paylaşılan havuza anlamlı bir şekilde entegre edilmeli, paylaşılan ve kişisel depolar aynı anda geliştiricinin kullanımına açık olmalı ve bunlar arasında nesneler kolayca aktarılmalıdır.

    1. Gerekli konfigürasyonda "istemci-sunucu" uygulamaları geliştirebilme

    Geliştirilmiş bir grafiksel uygulama geliştirme ortamının (birden çok pencere, çeşitli standart grafik nesneleri, kullanılan çeşitli yazı tipleri vb.) uygulamayı uygulayan bir "istemci" parçasına ayrıştırma (bölümleme) olasılığı ile bir kombinasyonunu ifade eder. bir kullanıcı ekranı arayüzü ve bir "sunucu" bölümü. Aynı zamanda, uygulamanın tek tek bileşenlerinin "istemci" ve "sunucu" arasında, uygulamanın bir bütün olarak maksimum verimliliğini sağlayan en uygun platforma taşınması ve aynı zamanda kullanım imkanı da mümkün olmalıdır. uygulama sunucusu (işlem yöneticisi).

    1. Açık mimari ve dışa/içe aktarma yetenekleri

    Kullanılan veri formatları ve uygulama programlama arayüzleri hakkında açık ve halka açık bilgiler, üçüncü taraf araçlarının entegrasyonuna ve bir sistemden diğerine nispeten ağrısız geçişe izin vermelidir. İhracat/ithalat yetenekleri, bir IC için analiz, tasarım ve uygulama aşamalarında elde edilen spesifikasyonların başka bir IC tasarlamak için kullanılabileceği anlamına gelir. Spesifikasyonların çeşitli CASE araçlarına aktarılması/içe aktarılması yoluyla yeniden tasarım ve uygulama sağlanabilir.

    1. Rusya'daki teknik desteğin kalitesi, satın alma ve destek maliyeti, başarılı kullanım deneyimi

    Bu, kalifiye distribütörlerin ve danışmanların mevcudiyeti, kullanıcı hizmetinin hızı, ürün için yüksek kaliteli teknik destek ve eğitim ve büyük geliştirici ekipleri için kullanım metodolojisi (sistemi kullanma pratiği hakkında bilgilerin mevcudiyeti, dokümantasyon kalitesi, örnekler ve eğitim kursları ile eksiksizlik, pilot projelerin mevcudiyeti). Yeni teknolojilerde eğitimin maliyeti önemlidir, ancak eğitimsiz uzmanlar tarafından modern karmaşık teknolojilerin kullanılmasından kaynaklanan kayıplar çok daha yüksek olabilir.

    Ayrıca, teknoloji bir yıl boyunca seçilmediği için araç satıcıları sürdürülebilir olmalıdır ve aynı zamanda şunları da sağlamalıdır: iyi destek Rusya topraklarında (yardım hattı, danışma, eğitim, danışmanlık), muhtemelen distribütörler aracılığıyla.

    Maliyete gelince, ücretsiz geçici lisans alma olasılığı, CASE araçlarının bir iş istasyonu için lisans maliyeti, çok sayıda lisans satın alınması durumunda şirket tarafından sağlanan indirimler, ihtiyaç dikkate alınmalıdır. işletim uygulamaları vb. için çalışma zamanı sürümleri satın alın. Aynı zamanda bir ürünün maliyeti kendi içinde değil, ürünün yeteneklerine uygunluğu açısından değerlendirilmelidir.

    1. Öğrenme ve kullanım kolaylığı

    dikkate alınır aşağıdaki özellikler:

    • aracın geliştirme ekibinin özelliklerine ve potansiyel yeteneklerine uygunluğu;
    • kullanıcı arayüzünün erişilebilirliği;
    • eğitim için gereken süre;
    • Kurulum kolaylığı;
    • dokümantasyon kalitesi;
    • hacim el emeği IS'nin eşlik ettiği
  • Proje dokümantasyonunun kalitesinin sağlanması
  • Bu gereklilik, CASE araçlarının açıklamaları ve belgeleri eksiksizlik ve tutarlılık açısından ve ayrıca bu metodolojide (GOST, ESPD dahil) benimsenen standartlar ve kurallara uygunluk açısından analiz etme ve kontrol etme becerisini ifade eder. Analiz sonucunda, proje dokümantasyonunda var olan çelişkileri veya eksiklikleri gösteren bilgiler üretilmelidir. Kullanıcılar tarafından tanımlanan yeni belge biçimleri oluşturmak da mümkün olmalıdır.

    1. Genel kabul görmüş, standart notasyonların ve kuralların kullanımı

    Projenin farklı geliştirici ekipleri tarafından yürütülebilmesi için, tasarım süreci başlamadan önce standartlar şeklinde biçimlendirilmesi gereken standart modelleme yöntemlerinin ve standart notasyonların kullanılması gerekir. Tasarım standartlarına uyulmaması, geliştiricileri bu aracın üreticisine bağımlı hale getirir, tasarım kararlarının doğruluğunu resmi olarak kontrol etmeyi zorlaştırır ve ek geliştirme ekiplerini çekme, uygulayıcıları değiştirme ve projeyi yabancılaştırma olasılığını azaltır, çünkü çok sayıda uzman tanıdıktır. bu yöntemle (notasyon) sınırlandırılabilir.

    Yapılan analiz sonucunda, hiçbirinin olmadığı ortaya çıkabilir. mevcut çare tüm ana kriterleri yeterince karşılamamaktadır ve projenin tüm ihtiyaçlarını karşılamamaktadır. Bu durumda, temelinde tek bir teknolojik ortam oluşturmak için bir dizi araç kullanılabilir.

    Kriterler, değerlendirme ve seçim süreçleri için temel oluşturur ve birçok şekilde olabilir:

    Gereken bellek miktarı gibi çok çeşitli değerlerde sayısal ölçümler;

    1'den 5'e kadar bir puan olarak ifade edilen öğrenme kolaylığı gibi sınırlı bir değer aralığındaki sayısal ölçüler;

    Postscript belgeleri oluşturma yeteneği gibi ikili ölçümler (doğru/yanlış, evet/hayır);

    CASE olanağının desteklendiği platformlar gibi bir veya daha fazla sonlu değer kümesi alabilen önlemler.

    Tipik bir değerlendirme ve/veya seçim süreci, bir dizi farklı türde kriter içerebilir.

    Kriterler kümesinin yapısı, Şek. 4.3. Her kriter, belirli bir sürecin özellikleri dikkate alınarak bir uzman tarafından seçilmeli ve uyarlanmalıdır. Çoğu durumda, aşağıda açıklanan birçok kriterden yalnızca bazıları kabul edilebilir ve ek kriterler de eklenir. Kullanılan kriter setinin seçimi ve iyileştirilmesi, değerlendirme ve/veya seçim sürecinde kritik bir adımdır.

    fonksiyonel özellikler

    Bu kriterler, bir CASE aracının işlevsel özelliklerini belirlemeye yöneliktir. Sırayla, bir dizi gruba ve alt gruba ayrılırlar.

    BEN. Çalışma ortamı:

    1. Tasarım ortamı:

    Yaşam döngüsü süreci desteği - CASE aracı tarafından desteklenen yazılım yaşam döngüsü süreçleri ve etkinlikleri kümesini tanımlar. Bu tür süreç ve faaliyetlere örnek olarak gereksinim analizi, tasarım, kodlama, test, değerlendirme, bakım, kalite güvence, konfigürasyon yönetimi ve proje yönetimi verilebilir ve bunlar kullanıcı tarafından benimsenen yaşam döngüsü modeline bağlıdır;

    Kapsam - işlem işleme sistemleri, gerçek zamanlı sistemler, bilgi sistemleri ve diğer şeylerin yanı sıra artan güvenlik gereksinimleri olan sistemler;

    Desteklenen uygulamaların boyutu - kod satırı sayısı, iç içe geçme düzeyleri, veritabanı boyutu, veri öğelerinin sayısı, yapılandırma yönetimi nesnelerinin sayısı gibi değerler üzerindeki sınırları tanımlar.

    Pirinç. 4.3. Kriter seti yapısı

    2. Yazılım/donanım:

    Gerekli teknik araçlar - işlemci türü, RAM miktarı ve disk belleği dahil olmak üzere CASE aracının çalışması için gerekli ekipman;

    Desteklenen donanım - giriş-çıkış aygıtları gibi bir CASE aracı tarafından kullanılabilen ekipman öğeleri;

    Gerekli yazılım - işletim sistemleri ve grafik kabuklar dahil olmak üzere CASE aracının çalışması için gerekli yazılım;

    Desteklenen yazılım - CASE aracı tarafından kullanılabilen yazılım ürünleri.


    3. Teknolojik ortam:

    Dil, veri tabanı, havuz, iletişim, grafik kullanıcı arayüzü, dokümantasyon, geliştirme, konfigürasyon yönetimi, güvenlik, iletişim standartları ve veri, kontrol ve kullanıcı arayüzü entegrasyonu ile ilgili teknoloji ortamı standartlarına uygunluk;

    Diğer araçlarla uyumluluk - doğrudan veri alışverişi (bu tür araçlara örnek olarak kelime işlemciler ve diğer dokümantasyon araçları, veritabanları ve diğer CASE araçları) dahil olmak üzere diğer araçlarla etkileşim yeteneği ve bir depoyu veya bunun bir bölümünü bir standarda dönüştürme yeteneği diğer araçlarla işleme biçimi;

    Desteklenen Yöntemler - CASE aracı tarafından desteklenen bir dizi yöntem ve teknik. Örnekler, yapısal veya nesne yönelimli analiz ve tasarımdır;

    Desteklenen diller - CASE aracı tarafından kullanılan tüm diller: programlama dilleri (Ada, C, C++), veritabanı ve sorgulama dilleri (DDL, SQL), grafik dilleri (Postscript, HPGL), tasarım gereksinimler belirtim dilleri ve işletim sistemi arayüzleri ( iş kontrol dilleri).

    II. Yazılım yaşam döngüsünün aşamalarına odaklanan işlevler:

    1. Modelleme:

    Diyagramlama - kullanıcının ilgi alanına giren çeşitli türlerde diyagramlar oluşturma ve düzenleme yeteneği (en yaygın diyagram türleri 2. ve 3. bölümlerde açıklanmıştır);

    Grafik analiz - grafik nesneleri analiz etme ve ayrıca tasarım bilgilerini grafik biçimde depolama ve sunma yeteneği. Çoğu durumda, grafik çözümleyiciler grafik oluşturma araçlarıyla entegre edilmiştir;

    Fonksiyonların, verilerin, arayüzlerin, yapının, kalitenin, performansın, tesislerin, ortamın, maliyetlerin ve programların açıklamalarını içeren gereksinim spesifikasyonlarının ve tasarım spesifikasyonlarının girilmesi ve düzenlenmesi;

    Gereksinim belirtimi ve tasarım belirtimi dili - resmi bir dil kullanarak belirtimleri içe aktarma, dışa aktarma ve düzenleme yeteneği;

    Veri modelleme - sistemin veri öğelerini ve bunların ilişkilerini tanımlayan bilgileri girme ve düzenleme yeteneği;

    Süreçlerin modellenmesi - sistemin süreçlerini ve ilişkilerini açıklayan bilgileri girme ve düzenleme yeteneği;

    Yazılım mimarisi tasarımı - yazılım mantıksal yapı tasarımı (modüllerin yapısı, arayüzler vb.);

    Simülasyon - ön uç ve performans (ör. yanıt süresi, kaynak kullanımı ve verim) dahil olmak üzere gereksinimlere ve/veya tasarım özelliklerine dayalı olarak sistem operasyonunun çeşitli yönlerini dinamik olarak simüle etme yeteneği;

    Prototipleme - gereksinimlerin özelliklerine ve / veya tasarım özelliklerine dayalı olarak tüm sistemin veya bireysel bileşenlerinin bir ön sürümünü tasarlama ve oluşturma yeteneği. Prototip oluşturma, esas olarak harici kullanıcı arayüzü ile ilgilidir ve kullanıcıların doğrudan katılımıyla gerçekleştirilir;

    Ekran formu oluşturma - gereksinim spesifikasyonlarına ve / veya tasarım spesifikasyonlarına dayalı olarak ekran formları oluşturma yeteneği;

    İzleme - gereksinimlerin belirlenmesinden nihai sonuçlara kadar sistemin işleyişinin uçtan uca analizi olasılığı (ÇBS için işlevsel ve diğer dış gereksinimler ile teknik çözümler ve tasarım sonuçları arasındaki yazışmaların ve ilişkilerin kurulması ve izlenmesi); ileri izleme (tüm gereksinimlerin dikkate alınıp alınmadığının kontrol edilmesi) ve geriye doğru izleme (dış gereksinimlerle ilgili olmayan tasarım çözümlerinin araştırılması);

    Tasarım özelliklerinin sözdizimsel ve anlamsal kontrolü - diyagramların sözdiziminin ve öğelerinin türlerinin kontrolü, işlevlerin ayrışmasının kontrolü, özelliklerin eksiksizlik ve tutarlılık açısından kontrol edilmesi;

    Diğer analiz türleri - belirli ek analiz türleri arasında algoritmalar, veri akışları, veri normalleştirme, veri kullanımı, kullanıcı arabirimi;

    Otomatik rapor tasarımı.

    Bu kriterler, yazılım gereksinimlerinin belirlenmesi için gerekli işlevleri yerine getirme yeteneğini belirler.

    2. Uygulama:

    Sözdizimsel kontrollü düzenleme - eş zamanlı sözdizimsel kontrolle bir veya daha fazla dilde kaynak kodlarını girme ve düzenleme yeteneği;

    Kod oluşturma - tasarım özelliklerine göre bir veya birkaç dilde kod üretme yeteneği. Oluşturulan kod türleri, normal program kodunu, veritabanı şemasını, sorguları, ekranları/menüleri içerebilir;

    Kod derleme;

    Kaynak kodu dönüştürme - kodu bir dilden diğerine dönüştürme yeteneği;

    Güvenilirlik analizi - hata sayısı vb. gibi yazılım güvenilirlik parametrelerini ölçme yeteneği;

    Tersine mühendislik - mevcut kaynak kodlarını analiz etme ve bunlara dayalı tasarım özellikleri oluşturma yeteneği;

    Kaynak kodunun yeniden yapılandırılması - mevcut bir kaynak kodun biçimini ve/veya yapısını değiştirme yeteneği;

    Kaynak Kodu Analizi - Kod boyutlandırma, karmaşıklık ölçümleri, çapraz referans oluşturma ve standart kontrolü;

    Hata ayıklama - programları izleme, darboğazları ve en sık kullanılan kod parçalarını vurgulama vb.

    Uygulama, sistemin yürütülebilir öğelerinin (program kodları) oluşturulmasıyla veya mevcut bir sistemin değiştirilmesiyle ilişkili işlevleri etkiler. Listelenen kriterlerin çoğu dile özgüdür.

    3. Test:

    Testlerin açıklaması - test verilerinin oluşturulması, test algoritmaları, gerekli sonuçlar, vb.;

    Operatörün eylemlerini düzeltme ve tekrarlama - klavye, fare vb. kullanarak operatör tarafından girilen verileri düzeltme, bunları düzenleme ve test senaryolarında çoğaltma yeteneği;

    Test senaryolarının otomatik olarak başlatılması;

    Regresyon testi - sistemdeki ve / veya ortamdaki farklılıkları belirlemek için daha önce gerçekleştirilen testleri tekrarlama ve değiştirme yeteneği;

    Test sonuçlarının otomatik analizi - beklenen ve gerçek sonuçların karşılaştırılması, dosyaların karşılaştırılması, sonuçların istatistiksel analizi vb.;

    Test kapsamı analizi - kaynak kodu kontrol araçları ve test kapsamı analizi ile donatma. Özellikle yürütülebilir ve çağrılabilir (veya çağrılabilir) operatörler, prosedürler ve değişkenler kontrol edilir;

    Performans analizi - programların performansını analiz etme yeteneği. Analiz edilen performans parametreleri, CPU ve bellek kaynaklarının kullanım derecesini, belirli veri öğelerine ve/veya kod bölümlerine erişim sayısını, zamanlamayı vb. içerebilir;

    Test sürecinde istisnai durumların analizi;

    Ortamın dinamik modellemesi, özellikle simüle edilmiş sistem girdilerini otomatik olarak oluşturma yeteneği.

    III. Genel Özellikler:

    1. Dokümantasyon:

    Metinleri ve grafikleri düzenleme - metin ve grafik formatlarında veri girme ve düzenleme yeteneği;

    Formları kullanarak düzenleme - kullanıcı tanımlı formları destekleme, formlara göre veri girme ve düzenleme yeteneği;

    Yayın sistemlerinin olanakları;

    Köprü metni işlevleri ve formatları için destek;

    Dokümantasyon standartlarına uygunluk;

    Depodan otomatik veri alma ve kullanıcı özelliklerine göre dokümantasyon oluşturma.

    2. Yapılandırma yönetimi:

    Erişim ve değişiklik kontrolü - veri öğelerine fiziksel düzeyde erişimi ve değişiklik kontrolünü kontrol etme yeteneği. Erişim kontrolü, bileşenlere erişim haklarını belirleme, veri öğelerini değişiklik için çıkarma, değişiklik süresince bunlara erişimi engelleme ve onları depoya geri yerleştirme yeteneğini içerir;

    İzleme değişiklikleri - geliştirme veya bakım sırasında sistemde yapılan tüm değişikliklerin düzeltilmesi ve günlüğe kaydedilmesi;

    Sürüm kontrolü - sistemin sürümleri ve toplu olarak kullanılan tüm bileşenleri hakkındaki verilerin bakımı ve kontrolü;

    Konfigürasyon yönetimi nesnelerinin durumunun muhasebeleştirilmesi - çeşitli konfigürasyon yönetimi nesnelerinin ardışık tüm sürümleri, içeriği ve durumu hakkında raporlar alma yeteneği;

    Sürümlerin ve değişikliklerin oluşturulması - sürümlerin ve değişikliklerin oluşturulması için gerekli eylem dizisinin kullanıcı açıklaması ve bu eylemlerin otomatik olarak yürütülmesi için destek;

    Arşivleme - veri öğelerini daha sonra kullanmak üzere otomatik olarak arşivleme yeteneği.

    3. Proje yönetimi:

    İş ve kaynak yönetimi - yazılım tasarım sürecinin görevlerin yapısı ve icracıların atanması, uygulama sırası, projenin bireysel aşamalarının tamamlanması ve bir bütün olarak proje açısından kontrolü ve yönetimi; Planlanan verileri, gerçek verileri ve bunların analizini destekleme yeteneği. Tipik veriler programları (takvimi, çalışma saatlerini, tatilleri vb. hesaba katarak), bilgisayar kaynaklarını, personel dağılımını, bütçeyi vb. içerir;

    Tahmin - kullanıcılar tarafından girilen maliyetleri, programı ve diğer tasarım parametrelerini değerlendirme yeteneği;

    Test prosedürü yönetimi - planlanan prosedürlerin zamanlamasını yönetme, test sonuçlarını düzeltme ve kaydetme, raporları oluşturma vb. gibi prosedürlerin ve test programının yönetimi için destek;

    Kalite yönetimi - ilgili verilerin girişi, analizleri ve raporların oluşturulması;

    Düzeltici Eylem - Sorun raporlama dahil olmak üzere düzeltici eylem yönetimi desteği.

    Yukarıdaki kriterler, yazılım yaşam döngüsünün tüm süreç ve aşamalarını kapsayan CASE araçlarının işlevlerini tanımlar. Tüm bu işlevler depo aracılığıyla desteklenir.

    Güvenilirlik:

    Havuz yönetimi - proje verilerinin bütünlüğünün kontrolü ve sağlanması;

    Otomatik yedekleme (sağlayıcı tanımlı veya kullanıcı planlı);

    Güvenlik - yetkisiz erişime karşı koruma;

    Hata işleme - sistemdeki hataları algılama, kullanıcıyı bilgilendirme, kesinti anında doğru kapatma veya durumu kaydetme;

    Kritik uygulamalarda hata analizi.

    Kullanım kolaylığı:

    Kullanıcı arayüzünün rahatlığı - sık kullanılan ekran öğelerinin, veri giriş yöntemlerinin vb. konum ve sunumunun rahatlığı;

    Yerelleştirme (belirli bir ülkenin gereksinimlerine uygun olarak);

    Geliştirme kolaylığı (fonların geliştirilmesi için emek ve zaman maliyetleri);

    Belirli kullanıcı gereksinimlerine uyarlanabilirlik (farklı alfabeler, metin ve grafik sunum modları (soldan sağa, yukarıdan aşağıya), farklı tarih formatları, giriş / çıkış yöntemleri (ekran formları ve formatları), metodolojideki değişiklikler (grafik gösterimlerdeki değişiklikler, kurallar, özellikler ve kompozisyon önceden tanımlanmış nesneler), vb.);

    Dokümantasyon kalitesi - eksiksizlik, anlaşılabilirlik, okunabilirlik, kullanışlılık vb.;

    Eğitim materyallerinin mevcudiyeti ve kalitesi (bilgisayar tabanlı eğitim materyalleri, öğretim yardımcıları, kurslar);

    CASE araçlarının etkili kullanımı için gerekli bilgi düzeyi - nitelikler ve deneyim için gereksinimler;

    CASE aracıyla çalışması kolay (hem yeni başlayanlar hem de ileri düzey kullanıcılar için);

    Kullanıcı arayüzünün tekdüzeliği (bu organizasyonda kullanılan diğer araçlarla ilişkili olarak);

    Çevrimiçi ipuçları (tamlık ve kalite);

    Teşhis kalitesi - kullanıcı için teşhis mesajlarının anlaşılırlığı ve kullanışlılığı;

    Kullanıcı eylemlerine izin verilen yanıt süresi (ortama bağlı olarak);

    Sürümleri yüklemek ve güncellemek kolaydır.

    Yeterlik:

    Kabul edilebilir bir performans düzeyi sağlayan, işlemcinin optimum harici ve RAM boyutu, türü ve performansı için gereksinimler;

    İş Yükü Verimliliği - Bir CASE aracının, kullanıcının işinin yoğunluğuna bağlı olarak işlevlerini yerine getirmedeki etkinliği (örneğin, belirli işlevleri gerçekleştirmek için gereken tuş vuruşlarının veya fare düğmelerinin sayısı);

    Performans - CASE aracının belirli görevleri gerçekleştirmek için harcadığı süre (örneğin, sorgu yanıt süresi, 10 bin satırlık kodun analiz süresi). Bazı durumlarda, performans değerlendirme verileri dış kaynaklardan elde edilebilir.

    bakım:

    Tedarikçinin destek düzeyi - sorunları çözme, yeni sürümler sunma, ek özellikler sağlama hızı;

    Güncelleme izlenebilirliği - yeni sürümler ile mevcut sürümler arasındaki farklara hakim olma kolaylığı;

    Güncellemelerin uyumluluğu - örneğin giriş veya çıkış verileri açısından uyumluluk dahil olmak üzere yeni sürümlerin mevcut sürümlerle uyumluluğu;

    Nihai ürünün bakımı - yazılım ve belgelerde değişiklik yapma kolaylığı.

    taşınabilirlik:

    İşletim sistemi sürümleriyle uyumluluk - aynı işletim sisteminin farklı sürümlerinin bulunduğu ortamda çalışabilme, CASE aracını işletim sisteminin yeni sürümleriyle çalışacak şekilde değiştirme kolaylığı;

    CASE aracının farklı sürümleri arasında veri taşınabilirliği;

    Dokümantasyon, iletişim ve kullanıcı arabirimi, pencereli arabirim, programlama dilleri, sorgulama dilleri vb. dahil olmak üzere taşınabilirlik standartlarına uyumluluk.

    Genel kriterler:

    Satın alma, kurulum, ilk bakım ve eğitim dahil olmak üzere CASE aracı maliyetleri. Tek kopya, birden çok kopya, yerel lisans, işletme lisansı, ağ lisansı dahil olmak üzere gerekli tüm yapılandırmalar için fiyatlandırmayı göz önünde bulundurun;

    CASE araçlarının tanıtılmasının tahmini etkisi - üretkenlik düzeyi, kalite vb. Böyle bir değerlendirme ekonomik bir analiz gerektirebilir;

    Distribütör Profili - genel göstergeler distribütör yetenekleri. Distribütörün profili, organizasyonunun büyüklüğünü, iş süresini, mali durumunu, ek ürünlerin listesini, iş bağlantılarını (özellikle ürünün diğer distribütörleriyle), planlanan geliştirme stratejisini içerebilir;

    Tedarikçi sertifikasyonu - yazılım geliştirme alanında uzman kuruluşlardan alınan sertifikalar (örneğin, SEI (Yazılım Mühendisliği Enstitüsü) ve ISO (Uluslararası Standardizasyon Örgütü)), tedarikçinin yazılım oluşturma ve sürdürme alanındaki yeterliliğinin tatmin edici olduğunu onaylar. bazı minimum gerekli veya iyi tanımlanmış gereksinimler. Sertifikasyon gayri resmi olabilir, örneğin tedarikçinin performansının analizine dayalı olabilir;

    Lisanslama politikası - mevcut lisanslama seçenekleri, kopyalama hakkı (medya ve belgeler), ikincil kullanım için herhangi bir kısıtlama ve / veya ceza (bu, CASE aracının bazı bileşenlerini içeren ürünlerin CASE aracının kullanıcısı tarafından satışı anlamına gelir) ürünlerin geliştirilmesi);

    İhracat kısıtlamaları;

    Ürün profili - Genel bilgi kullanım ömrü, satılan kopya sayısı, kullanıcı grubunun varlığı, boyutu ve etkinlik düzeyi, sorun raporlama sistemi, ürün geliştirme programı, uygulama karması, hatalar vb. dahil olmak üzere ürün hakkında;

    Satıcı desteği - Satıcı tarafından CASE araçlarının kullanıcılarına sağlanan hizmetlerin kullanılabilirliği, tepkiselliği ve kalitesi. Bu tür hizmetler arasında telefon hattı, yerel teknik destek, kuruluş içi destek;

    Eğitimin mevcudiyeti ve kalitesi (eğitim tedarikçinin tesislerinde, kullanıcının tesislerinde veya başka bir yerde yapılabilir);

    CASE araçlarını kullanıcının kuruluşunda uygulamak için özelleştirme gerekir. Bir örnek, merkezi bir CASE aracını dağıtılmış bir ortamda tek bir paylaşılan veritabanıyla kullanmanın bir yolunu tanımlamak olabilir.

    CASE araçlarını seçmek için kriterleri tanımlamaya yönelik bir yaklaşım örneği*

    CASE araçlarının, girişte listelenen özelliklere sahip büyük bir standart EIS projesinde kullanılacağı varsayılmaktadır. Genel olarak, belirli bir uygulama için CASE araçlarını seçme stratejisi, sırayla kullanılan tasarım yöntemlerini belirleyen gelecekteki EIS projesinin (tasarım sürecine dahil olan uzmanların nitelikleri dahil) amaçlarına, gereksinimlerine ve kısıtlamalarına bağlıdır. .

    Araçların seçiminde belirleyici faktörün kullanılan tasarım yöntemleri ve teknolojileri olduğu, tersinin olmadığı vurgulanmalıdır. Bu bakış açısına göre, CASE araçlarını yöntemlerden ayrı olarak karşılaştırmanın bir anlamı yoktur, çünkü EIS prensip olarak herhangi bir yolla geliştirilebilir.

    Geleneksel olarak, CASE araçlarını seçme sorununu tartışırken, konu alanını (SADT, Gein-Serson, vb.) Analiz etmek için şu veya bu yöntemin uygulanmasının özelliklerine çok dikkat edildi. Tabii ki, resimsel ve tanımlayıcı araçların zenginliği, gereksinimlerin oluşturulması aşamasında kuruluşun faaliyetlerinin en eksiksiz ve yeterli modelini oluşturmayı mümkün kılar. Öte yandan, nihai sonuçlar - veritabanları ve uygulamalar hakkında konuşursak, bazı açıklamaların pratikte bunlara yansımadığı, tamamen bildirimsel kaldığı (çıktıda, her durumda, bir açıklama alacağız) ortaya çıkıyor. çoğu doğrudan kuruluşun iş modellerinden türetilmemiş ekran formları olan minimum bir bütünlük uygulama kodu seti ile tablo görünümünde veritabanı). Deneyimli analistler ve tasarımcılar, bu araçta hangi özel yöntemin uygulandığından bağımsız olarak her zaman istenen sonuca az ya da çok çabayla ulaşacaktır. Bu, elbette, yöntemin önemli olmadığı anlamına gelmez. Aksine, tanımlayıcı araçların yokluğu veya eksikliği, proje üzerindeki çalışmayı en başından önemli ölçüde engelleyebilir. Bununla birlikte, başarısızlığı çok daha büyük zorluklara yol açabilen başka kriterler sıklıkla ön plana çıkar.

    Bölümde belirtildiği gibi. 1.3'te tasarım teknolojisi, yaşam döngüsünün tüm aşamalarında gerçekleştirilen süreçlerin otomasyonunu sağlayan bir dizi koordineli CASE aracıyla desteklenmelidir. İlk bakışta, çeşitli üreticilerin bileşenlerinden gerekli donanım platformunu oluşturmak mümkünse, her biri kendi sınıfında dünya liderlerinden biri olan farklı araçları seçip birleştirmek de bir o kadar kolay görünüyor. Bununla birlikte, araçlar için, ekipmandan farklı olarak, nihai ürünlerin (programlar, veritabanları ve bunların arayüzleri) ana özelliklerine ilişkin uluslararası standartlar iyi gelişmemiştir. Projenin bileşenlerinin tek bir ürüne entegre edilmesi gerektiğinden, prensipte (aynı sınıf içinde bile) farklı yöntemlere yönlendirilebilen eşlenik araçları değil, yalnızca eşlenik araçları dikkate almak mantıklıdır. Aynı zamanda, aynı değilse bile en azından yakın yöntemleri destekleyen CASE araçları kompleksinde bu tür araçları seçmek gerekir.

    Yukarıda listelenen hususlara dayanarak, CASE araçlarını seçmek için aşağıdaki ana kriterler kabul edilir:

    1. Tam yazılım yaşam döngüsü için destek, gelişiminin evrimini sağlamak Tüm yazılım yaşam döngüsü, Bölüm 1'de listelenen araçlar seti tarafından desteklenmelidir. 4.1. Bu durumda, aşağıdaki özellikler dikkate alınmalıdır:

    Toplu, coğrafi olarak dağıtılmış modellerin, tasarım özelliklerinin ve çeşitli araçların kullanıldığı uygulamaların geliştirilmesinin mevcudiyeti (entegrasyon, test etme ve hata ayıklama dahil);

    Tipik bir projeyi çeşitli sistem ve teknik platformlara (donanım, işletim sistemleri ve DBMS) ve uygulama nesnelerinin organizasyonel ve ekonomik özelliklerine uyarlama ihtiyacı;

    Mevcut gelişmelerle entegrasyon ihtiyacı (uygulama tersine mühendislik ve veritabanı dönüştürme dahil). Mevcut yazılımlar için, eski ortamdan yenisine sorunsuz bir geçiş, minimum yeniden çalışma ve yeni bir sistemin oluşturulmasına yönelik çalışmaya başlamadan önce uygulanan operasyonel veritabanları ve uygulamalar için destek ile sağlanmalıdır.

    2. Projenin bütünlüğünün sağlanması ve durumunun izlenmesi. Bu kriter, yazılım oluşturmak, sürdürmek ve geliştirmek için tek bir teknolojik ortamın varlığını ve ayrıca havuzun bütünlüğünü varsayar. Destekleyici modeller için tek bir CASE aracının kullanılmasının yanı sıra ilgili araçları geliştiren firmalar tarafından onaylanan ve desteklenen bireysel araçlar arasında yazılım ve teknolojik arayüzlerin mevcudiyeti yoluyla birleşik bir teknolojik ortam sağlanmalıdır. Özellikle CASE araçları ile uygulama geliştirme araçları arasındaki arabirim iki ana işlevi yerine getirmelidir: 1) tek bir ortam içinde CASE aracı tarafından uygulanan uygulama mantığının açıklamasından bir kullanıcı arabiriminin (ekran formları) geliştirilmesine doğrudan geçiş; 2) veritabanı açıklamasının CASE aracı deposundan uygulama geliştirme aracı deposuna aktarılması ve bunun tersi de geçerlidir. Projeyle ilgili tüm bilgiler, projenin tutarlılığını, tutarlılığını, eksiksizliğini ve minimum fazlalığını ve ayrıca düzenleme işlemlerinin doğruluğunu korurken otomatik olarak havuza yerleştirilmelidir. Bu, depoyu çeşitli yollarla güncelleme olasılığını ortadan kaldırarak veya önemli ölçüde sınırlandırarak elde edilebilir. CASE aracı çerçevesinde, diyagram ayrıştırmalarının uygunluk kontrolünün yanı sıra çeşitli tipteki diyagramların (örneğin, veri akış diyagramları ve ER diyagramları) uygunluk kontrolü sağlanmalıdır.

    Geliştiricilerin ayrılığı ve büyük bir projenin zaman aralığı bağlamında bütünlük gerekliliğine uyulmaması, durumu üzerinde kontrol kaybı anlamına gelebilir.

    3. Yazılım ve donanım platformundan ve VTYS'den bağımsızlık. Kriter, yazılımın çalışma ortamının heterojenliği ile belirlenir. Bu bağımsızlığın iki bileşeni olabilir: geliştirme ortamından bağımsız olma ve uygulama işletim ortamından bağımsız olma. Çeşitli platformlar için CASE araçlarının uyumlu sürümlerinin ve ilgili ağ protokollerinin, işlem yöneticilerinin ve DBMS'nin sürücülerinin bulunmasıyla sağlanır.

    4. Geliştirici gruplarının eş zamanlı çalışması için destek. Geliştirilen CASE araçları, geliştirme personelinin yetkilerini ayırma ve bireysel çalışmaları ortak bir projede birleştirme yeteneğine sahip olmalıdır. Veritabanı tasarımcılarının ve uygulama geliştiricilerinin eşzamanlı (belirli bir ağ yapılandırmasında) çalışması sağlanmalıdır (böyle bir durumda, uygulama geliştiricileri, tasarımının CASE araçları tarafından tamamen tamamlanmasını beklemeden veritabanıyla çalışmaya başlayabilir). Aynı zamanda, tüm uzman gruplarına yeterli araçlar sağlanmalı ve çeşitli geliştiriciler tarafından projede yapılan değişiklikler tutarlı ve doğru olmalıdır. Her geliştirici, paylaşılan havuzun bir parçası veya kopyası olan kendi kişisel deposuyla çalışabilmelidir. Geliştiriciler tarafından yapılan tüm değişiklikler, paylaşılan havuza anlamlı bir şekilde entegre edilmeli, paylaşılan ve kişisel depolar aynı anda geliştiricinin kullanımına açık olmalı ve bunlar arasında nesneler kolayca aktarılmalıdır.

    5. Gerekli konfigürasyonda "istemci-sunucu" uygulamaları geliştirebilme becerisi. Uygulamayı uygulayan bir "istemci" parçaya bölme (bölümleme) olasılığı ile gelişmiş bir grafik uygulama geliştirme ortamının (çoklu pencere, çeşitli standart grafik nesneleri, kullanılan çeşitli yazı tipleri vb.) varlığını ifade eder. kullanıcı ekranı arayüzü ve bir "sunucu" bölümü. Aynı zamanda, uygulamanın tek tek bileşenlerinin "istemci" ve "sunucu" arasında, uygulamanın bir bütün olarak maksimum verimliliğini sağlayan en uygun platforma taşınması ve aynı zamanda kullanım imkanı da mümkün olmalıdır. uygulama sunucusu (işlem yöneticisi).

    6. Açık mimari ve dışa/içe aktarma yetenekleri. Kullanılan veri formatları ve uygulama programlama arayüzleri hakkında açık ve halka açık bilgiler, üçüncü taraf araçlarının entegrasyonuna ve bir sistemden diğerine nispeten ağrısız geçişe izin vermelidir. İhracat/ithalat yetenekleri, bir sistem için gereksinimler, tasarım ve uygulama aşamaları sırasında elde edilen spesifikasyonların başka bir sistemi tasarlamak için kullanılabileceği anlamına gelir. Spesifikasyonların çeşitli CASE araçlarına aktarılması/içe aktarılması yoluyla yeniden mühendislik ve uygulama sağlanabilir.

    7. Rusya'daki teknik desteğin kalitesi, satın alma ve destek maliyeti, başarılı kullanım deneyimi. Bu kriter, kalifiye distribütörlerin ve danışmanların mevcudiyetini, hızlı kullanıcı servisini, yüksek kaliteli teknik desteği ve ürün için eğitimi ve büyük geliştirici ekipleri için kullanımı için metodolojiyi (sistemi kullanma pratiği hakkında bilgilerin mevcudiyeti, dokümantasyon kalitesi, örnekler ve eğitim kursları ile eksiksizlik, pilot projelerin mevcudiyeti). Yeni teknolojilerde eğitimin maliyeti önemlidir, ancak eğitimsiz uzmanlar tarafından modern karmaşık teknolojilerin kullanılmasından kaynaklanan kayıplar çok daha yüksek olabilir.

    Buna ek olarak, teknoloji bir yıl boyunca seçilmediği için takım firmaları sürdürülebilir olmalı ve muhtemelen distribütörler aracılığıyla Rusya'da iyi destek (yardım hattı, danışma, eğitim, danışmanlık) sağlamalıdır.

    Maliyet olarak, ücretsiz geçici lisans alma olasılığı, CASE araçlarının bir iş yeri için lisans maliyeti, çok sayıda lisans satın alınması durumunda şirketin sağladığı indirimler, satın alma ihtiyacı dikkate alınmalıdır. işletim uygulamaları vb. için çalışma zamanı sürümleri. Aynı zamanda bir ürünün maliyeti kendi içinde değil, ürünün yeteneklerine uygunluğu açısından değerlendirilmelidir.

    8. Öğrenmesi ve kullanması kolay. Bu kriter aşağıdaki özellikleri içerir:

    Aracın, geliştirme ekibinin özelliklerine ve potansiyel yeteneklerine uygunluğu;

    Kullanıcı arayüzünün erişilebilirliği;

    Eğitim için gereken süre;

    Kurulumu kolay;

    Dokümantasyon kalitesi;

    Yazılım bakımındaki el emeği miktarı.

    9. Proje dokümantasyonunun kalitesinin sağlanması. Bu kriter, CASE araçlarının açıklamaları ve belgeleri eksiksizlik ve tutarlılık açısından ve ayrıca bu metodolojide (GOST, ESPD dahil) benimsenen standartlar ve kurallara uygunluk açısından analiz etme ve kontrol etme becerisini ifade eder. Analiz sonucunda, proje dokümantasyonunda var olan çelişkileri veya eksiklikleri gösteren bilgiler üretilmelidir. Kullanıcılar tarafından tanımlanan yeni belge biçimleri oluşturmak da mümkün olmalıdır.

    10. Genel kabul görmüş standart notasyonların ve kuralların kullanımı. Projenin farklı geliştirici ekipleri tarafından yürütülebilmesi için, tasarım süreci başlamadan önce standartlar şeklinde biçimlendirilmesi gereken standart modelleme yöntemlerinin ve standart notasyonların kullanılması gerekir.

    Tasarım standartlarına uyulmaması, geliştiricileri bu aracın üreticisine bağımlı hale getirir, tasarım kararlarının doğruluğunu resmi olarak kontrol etmeyi zorlaştırır ve ek geliştirme ekiplerini çekme, uygulayıcıları değiştirme ve projeyi yabancılaştırma olasılığını azaltır, çünkü çok sayıda uzman tanıdıktır. bu yöntemle (notasyon) sınırlandırılabilir.

    Yapılan analiz sonucunda, mevcut fonların hiçbirinin listelenen kriterlerin tamamını gereken ölçüde karşılamadığı ve projenin tüm ihtiyaçlarını karşılamadığı ortaya çıkabilir. Bu durumda, temelinde tek bir teknolojik ortam oluşturmak için bir dizi araç kullanılabilir.

    PİLOT PROJENİN UYGULANMASI

    Seçilen CASE aracının kuruluşta tam ölçekli uygulamasından önce, amacı önceki aşamalarda alınan kararların doğruluğunu deneysel olarak doğrulamak ve uygulamaya hazırlanmak olan bir pilot proje yürütülür.

    Bir pilot proje, CASE aracının amaçlanan ortamda ilk gerçek kullanımını temsil eder ve genellikle CASE aracının değerlendirme sırasında elde edilenden daha geniş bir ölçekte kullanımını içerir. Bir pilot proje, aracın amaçlandığı gerçek projelerin birçok özelliğine sahip olmalıdır. Aşağıdaki hedeflere sahiptir:

    Değerlendirme ve seçim sonuçlarının geçerliliğini onaylayın;

    CASE aracının bu organizasyonda kullanım için gerçekten uygun olup olmadığını ve eğer öyleyse, hangi alanda uygulamasının en uygun olduğunu gösterin;

    Pratik bir uygulama planı geliştirmek için gerekli bilgileri sağlamak;

    Kullanıcının CASE aracını kullanma konusunda kendi deneyimini kazanmasına yardımcı olun.

    Pilot proje, araç yüklendikten sonra CASE aracının kalitesini ve satıcı desteğini değerlendirmek için gereken önemli bilgileri sağlar.

    Pilot projenin önemli bir işlevi, CASE aracını satın alıp almamaya karar vermektir. Bir pilot proje genellikle nispeten az sayıda lisansın alınmasını ve az sayıda uzmanın eğitimini gerektirdiğinden, proje başarısızlığı daha sonra daha büyük ve daha maliyetli başarısızlıkları önler.

    Bir pilot projede yeni bir CASE teknolojisinin ilk kullanımı dikkatlice planlanmalı ve kontrol edilmelidir. Pilot proje beş adım içermektedir (Şekil 4.4).

    Adım 1. Pilot projenin karakterizasyonu. Pilot proje aşağıdaki özelliklere sahip olmalıdır:

    Konu alanının tipikliği. CASE aracının kapsamının nihai tanımını kolaylaştırmak için pilot projenin konu alanı, kuruluşun normal faaliyetlerini temsil etmelidir. Proje, bir pilot projeden tesisin büyük ölçekli kullanımına geçmek için gerekli olan herhangi bir ek teknoloji, eğitim veya desteğin belirlenmesine yardımcı olmalıdır. Bu kısıtlamalar dahilinde, pilot proje küçük ama anlamlı olmalıdır.

    ölçeklenebilirlik. Pilot projede elde edilen sonuçlar, aracın ölçeklenebilirliğini göstermelidir. Amaç, bu aracın geçerli olduğu projelerin kapsamı hakkında net bir fikir edinmektir.

    Temsil edilebilirlik. Bir pilot proje alışılmadık veya kuruluşa özgü olmamalıdır. Tüm kuruluş tarafından iyi anlaşılan bir konu alanıyla ilgili sorunları çözmek için bir CASE aracı kullanılmalıdır.

    kritiklik. Bir pilot proje, ilgi odağı olmak için önemli olmalı, ancak bir bütün olarak organizasyonun başarısı için kritik olmamalıdır. Yeni bir teknolojinin ilk tanıtımının bazı riskler içerdiği kabul edilmelidir. Pilot proje seçerken şu ikilemi çözmek gerekiyor: Küçük bir projenin başarısı gözden kaçabilir, öte yandan önemli bir projenin başarısızlığı aşırı eleştiriye neden olabilir.

    Proje ekibinin hazır olması. Proje ekibi yenilikçi, teknik olarak olgun ve teknoloji ve konu alanında kabul edilebilir düzeyde deneyim ve bilgiye sahip olmalıdır. Öte yandan, grup bir bütün olarak organizasyonun özelliklerini minyatür olarak yansıtmalıdır.

    Çoğu durumda, ideal bir pilot projeyi uygulama arzusu ile kuruluşun gerçek sınırlamaları arasında bir denge vardır. Kuruluş, bir pilot projeyi, öncelikle CASE aracının kullanım şeklinin gelecek planları ile örtüşecek ve ikinci olarak yukarıda sıralanan özelliklerin kuruluşun gerçek koşullarıyla dengelenecek şekilde seçmelidir.

    Ayrıca kuruluş, pilot projenin süresini (ve genel uygulama sürecini) dikkate almalıdır. Çok uzun bir proje, yönetimin projeye olan ilgisini kaybetme riskiyle ilişkilidir.

    Pirinç. 4.4. Pilot proje adımları

    Adım 2. Bir pilot proje planlama. Mümkün olduğunca organizasyonun normal proje planlama sürecine uymalıdır. Plan aşağıdakilerle ilgili bilgileri içermelidir:

    Amaçlar, hedefler ve değerlendirme kriterleri;

    personel;

    prosedürler ve anlaşmalar;

    eğitim;

    Grafikler ve kaynaklar.

    Amaçlar, hedefler ve değerlendirme kriterleri. Pilot projenin beklenen sonuçları açıkça tanımlanmalıdır. Bu sonuçlara uygunluk derecesi, projenin müteakip değerlendirmesi için temel oluşturur. Böyle bir temel oluşturmak için aşağıdaki adımları gerçekleştirmelisiniz:

    Projeyi beklenen sonuçlar (yani nihai ürün) açısından tanımlayın. Açıklama, sunum şeklini ve sonuçların içeriğini içermelidir. Sözleşme gereklilikleri ve ilgili standartlar açıkça tanımlanmalıdır;

    Projenin genel hedeflerini, yani CASE araçlarının bu proje ortamında kullanılmasının ne kadar iyi ve ne ölçüde planlandığını formüle edin. CASE araçlarının kullanımının bir sonucu olarak proje belgelerinin kalitesindeki gelişme derecesini değerlendirmek bir hedef örneği olabilir;

    Hedefleri gerçekleştiren belirli görevleri belirleyin. Her hedef, ölçülebilir sonuçları olan bir (veya daha fazla) belirli görevle ilişkilendirilebilir. Böyle bir görevin bir örneği, bir CASE aracı kullanılarak ve onsuz elde edilen belgelerin kalitesinin karşılaştırmalı bir analizi olabilir. Dokümantasyon, yazılım gereksinimleri belirtimini, üst düzey ve ayrıntılı tasarım belirtimlerini içerebilir;

    Sonuçları değerlendirmek için kriterler belirleyin. Bir pilot projenin başarı derecesini belirlemek için yukarıda belirtilen görevlere dayalı bir dizi kriter kullanılmalıdır. Bir kriter örneği, proje dokümantasyonunun tutarlılık derecesi ve yazılım gereksinimlerinin uygulanmasının kontrol edilebilirliği olabilir. Kriter değerleri, pilot proje öncesinde elde edilen temel değerler ile karşılaştırılmalıdır.

    Kadro. Pilot projeye katılmak üzere seçilen kişiler, uygun yetkiye ve etkiye sahip olmalı ve yeni teknolojinin destekçisi olmalıdır. Ekip, yeni teknolojiyle ilgilenen ve onu nasıl kullanacağını anlayan hem teknik kişileri hem de yöneticileri içermelidir. Grup, yüksek iletişim becerilerine, örgütsel süreçler ve prosedürler ile konu alanına ilişkin bilgiye sahip olmalıdır. Ancak grup tamamen üst düzey profesyonellerden oluşmamalı, organizasyonun orta düzeyini temsil etmelidir.

    Birçok CASE aracı, proje dokümantasyonu oluşturma ve yapılandırma yönetimi ile ilgili yetenekler sağlar. Bunlarla ve yazılım geliştirme ve bakımın diğer ilgili yönleriyle ilişkili uzmanlar da gruba dahil edilmelidir.

    Pilot projenin tamamlanmasından sonra grup, yeni aracın yetenekleri ve onu kullanmaktan elde edilen deneyim hakkında kuruluşun geri kalanıyla bilgi paylaşmaya açık olmalıdır. Deneyimlerini ve bilgilerini yaymak için proje ekibini kuruluş genelinde dağıtmak istenebilir.

    prosedürler ve anlaşmalar. Pilot projede CASE araçlarının kullanımına ilişkin prosedürler ve anlaşmalar açıkça tanımlanmalıdır. Bu görev muhtemelen beklenenden daha uzun ve karmaşık olacaktır. Bu, dışarıdan uzmanların katılımını gerektirebilir. Bir pilot projenin başarısını etkileyebilecek prosedür ve kurallara örnek olarak yöntemler, teknik kurallar (özellikle adlandırma kuralları ve dizin yapısı kuralları, tasarım ve programlama standartları - santimetre. saniye 1.3) ve kurumsal anlaşmalar (özellikle, kaynakların kullanımı, yetkilendirme ve değişiklik kontrolü için muhasebe kuralları ve ayrıca inceleme, kalite kontrol ve raporlama prosedürleri).

    Pilot proje, mümkün olduğu ölçüde kuruluş içindeki mevcut prosedürleri ve anlaşmaları kullanmalıdır. Öte yandan, bir pilot proje sırasında, araçla ilgili deneyim kazanıldıkça verimsiz veya aşırı derecede kısıtlayıcı prosedürler ve anlaşmalar gelişebilir ve iyileşebilir. Aynı zamanda, bunlarda yapılması önerilen değişiklikler belgelenmelidir.

    Eğitim. Pilot proje için gerekli eğitim türleri ve miktarı belirlenmelidir. Planlanan eğitim üç tür ihtiyaç sağlamalıdır: teknik, yönetimsel ve motivasyonel. Eğitim için gereken kaynaklar (sınıflar ve ekipman, öğretmenler ve öğretim materyalleri) pilot proje planına uygun olmalıdır.

    Eğitim programı, hem eğitilecek profesyonelleri hem de almaları gereken eğitim türlerini tanımlamalıdır. Proje süresince yer alan eğitim, proje başladıktan sonra mümkün olan en kısa sürede başlamalıdır. Projenin başlamasından sonraki birkaç ay içinde kullanılmayacak olan araçlara, süreçlere veya yöntemlere ilişkin eğitim, gerçekten ihtiyaç duyuldukları zamanda planlanmalıdır.

    CASE aracı satıcıları genellikle sağladıkları araçların nasıl kullanılacağına ilişkin eğitim sunar. Ayrıca bazı araçlar için metodoloji eğitimi gerekebilir. Dışarıdan sağlanamayan bazı eğitim türleri ticari kuruluşlar kendi başlarına yapılmalıdır. Bu öğrenme türleri, organizasyonda yer alan süreçler bağlamında ve ayrıca bu ortamdaki diğer araçlarla bağlantılı olarak bir CASE aracının kullanımını içerir. Pilot proje planının eğitim kısmı, uygulama planına girdi olarak kullanılmalıdır.

    Gerekli eğitimin seçiminde aşağıdaki faktörler dikkate alınmalıdır:

    Öğretmen nitelikleri;

    Eğitimin belirli uzman gruplarının özelliklerine uygunluğu (örneğin, yöneticiler için genel bakış kursları, geliştiriciler için ileri düzey kurslar);

    Dersleri doğrudan işyerinde yürütme imkanı;

    Derinlemesine kurslar yürütme imkanı;

    Öğretmen eğitimi için fırsatlar.

    Zamanlama ve kaynaklar. Yürütülecek iş için kaynakları ve zaman dilimlerini (aşamaları) içeren bir program geliştirilmelidir. Kaynaklar personel, donanım, yazılım ve finansmanı içerir. Personel verileri, bir pilot projeyi başarıyla tamamlamak için gereken belirli becerileri veya beceri gereksinimlerini tanımlayabilir. Finansman, her iş türü için ayrı ayrı belirlenmelidir: CASE araçlarının satın alınması, kurulum, eğitim, bireysel tasarım aşamaları.

    Adım 3. Pilot projenin uygulanması. Plana göre gitmeli. Pilot projenin uygulanması ve raporların hazırlanması ile ilgili organizasyonel faaliyetler, Vaktinden. Projenin pilot niteliği, edinim, destek, inceleme ve yükseltmelere özel dikkat gerektirir.

    Kazanma. Bir CASE aracı seçildikten sonra satın alınmalı, proje ortamına entegre edilmeli ve pilot projenin gereksinimlerine göre yapılandırılmalıdır. Bu faaliyetin sınırları, değerlendirme ve seçim sürecinde yer alan faaliyetlere olduğu kadar, projede kullanılması için gerekli olan aracın değişiklik derecesine de bağlıdır.

    Satın alma süreci, sözleşme hazırlama, müzakere, lisanslama ve bu kılavuzların kapsamı dışında kalan diğer faaliyetleri içerebilir. Bu faaliyet, planlama sırasında dikkate alınması gereken zaman ve insan kaynakları gerektirir. Plan, sözleşme farklılıkları nedeniyle bu aşamada seçilen çözüm yolunun terk edilmesini içermelidir.

    Alet satın alındıktan sonra kurulmalı, test edilmeli ve hizmete alınmalıdır. Test, teslim edilen ürünün sözleşmenin gerekliliklerini karşıladığından, gerekli eksiksizliğe ve doğruluğa sahip olduğundan emin olmanızı sağlar. Kabul aşaması sözleşmede belirtilebilir. Onun gerçek terim pilot proje planında başlangıçta öngörülenden farklı olabilir. CASE aracının çalışması için tedarikçinin ortam parametrelerine ilişkin tüm gerekliliklerine uymaya özel dikkat gösterilmelidir.

    Kabul tamamlandıktan sonra bazı özelleştirme ve entegrasyon gerekebilir. Özelleştirme, proje ekibinin uzmanlarının gereksinimlerine göre arayüzlerin değiştirilmesinin yanı sıra erişim hakları ve ayrıcalıklarının yüklenmesini içerebilir. Özelleştirme, aracın kendisi tarafından sağlanan yetenekler dahilinde kalmalıdır. Bitmiş ürünleri kaynak kod düzeyinde değiştirmemelisiniz.

    Yeni bir araç başka bir araçla birlikte kullanılacaksa, araçlar arasındaki etkileşim ve gerekli entegrasyon belirlenmelidir. Yeni araçları mevcut araçlarla entegre etmek için özel kabuklar oluşturmanız gerekebilir. Karmaşık entegrasyonlar, üçüncü taraf uzmanların katılımını gerektirebilir.

    Destek. Mevcut destek, (anlaşma ile) tedarikçi yardım hattını ve yerel tedarikçi desteğini, kuruluş içindeki desteği, deneyimli kullanıcılar diğer kuruluşlarda ve kullanıcı gruplarına katılım.

    Dahili destek, araçları kurma ve kullanma konusunda bilgi sahibi olan kişilere erişimi içermelidir. Bu tür bir desteği almak için çeşitli seçenekler vardır (örneğin, araçla önceden deneyime sahip kuruluştaki bir uzmandan, değerlendirme ve seçim sürecindeki katılımcılardan veya deneyimli bir danışmandan). Bu tür bir destek özel olarak planlanmalı ve yönetilmelidir. Ağlarda çalışan veya çok kullanıcılı çalışmayı destekleyen havuzlara sahip araçlara özel dikkat gösterilmelidir.

    Uzmanlık. Pilot proje için organizasyonda var olan olağan proje inceleme prosedürleri de izlenmelidir. Aynı zamanda, projenin pilot yönlerine özel dikkat gösterilmelidir. Ek olarak, sınavların sonuçları CASE araçlarının başarılı kullanımının bir ölçüsü olarak hizmet etmelidir.

    Sürüm güncellemesi. CASE aracının kullanıcıları, pilot proje sırasında satıcıdan periyodik güncellemeler bekleyebilir. Aynı zamanda, bu sürümlerin entegrasyonu konusunda dikkatli bir tutum gereklidir. Bu güncellemelerin projenin ilerlemesi üzerindeki etkisi önceden değerlendirilmelidir. Yeni sürümler hem yeni özellikler sağlayabilir hem de yeni sorunlar ortaya çıkarabilir. Aynı zamanda yeni bir versiyon değiştirilmiş veya ek eğitim gerektirebilir ve ayrıca o noktaya kadar tamamlanmış işler üzerinde olumsuz bir etkisi olabilir.

    Adım 4. Pilot projenin değerlendirilmesi. Pilot projenin tamamlanmasından sonra, sonuçlar değerlendirilmeli ve kuruluşun ilk ihtiyaçları, CASE araçlarının başarılı bir şekilde uygulanmasına yönelik kriterler, temel ölçütler ve pilot proje için başarı kriterleri ile karşılaştırılmalıdır. Böyle bir değerlendirme, olası problemler ve CASE aracının kuruluş için uygunluğunu etkileyebilecek pilot projenin temel özellikleri. Ayrıca, aracın uygun olduğu kuruluş içindeki projeleri veya departmanları da belirtmelidir. Ek olarak, değerlendirme gelecekte uygulama sürecinin nasıl iyileştirilebileceği hakkında bilgi sağlayabilir.

    Bir pilot projeyi değerlendirme sürecinde, kuruluş aşağıdaki üç konuda pozisyonunu belirlemelidir:

    Bir CASE aracının uygulanması tavsiye edilir mi?

    Pilot projenin hangi spesifik özellikleri onun başarısına (veya başarısızlığına) yol açtı?

    Kuruluştaki hangi projeler veya departmanlar fonların kullanımından yararlanabilir?

    Adım 5. Uygulama hakkında karar vermek. Bu adım, kuruluşun CASE araçlarına yoğun bir şekilde yatırım yapmasını gerektirecektir. Fonlar kuruluşun beklentilerini karşıladıysa veya hatta aştıysa, bunları uygulama kararı oldukça basit ve hızlı bir şekilde alınabilir.

    Öte yandan, pilot projedeki fonların kendilerine yüklenen beklentileri karşılamadığı veya pilot projede tatmin edici bir şekilde kullanıldığı ortaya çıkabilir, ancak deneyimler fonlara daha fazla yatırım yapılmadığını göstermiştir. başarıyı garanti eder.

    Pilot projenin ve ilgili eylemlerin dört olası sonucu vardır:

    1. Pilot proje başarısız oldu ve analizi kuruluşun beklentilerinin yetersiz olduğunu gösterdi. Bu durumda kuruluş, projenin sonuçlarını daha gerçekçi beklentiler bağlamında revize edebilir.

    2. Pilot proje başarısız oldu ve analizi, seçilen araçların kuruluşun ihtiyaçlarını karşılamadığını gösterdi. Bu durumda, bir kuruluş bu araçları uygulamamaya karar verebilir, ancak CASE araçlarını değerlendirme ve seçme konusundaki ihtiyaçlarını ve yaklaşımını da yeniden gözden geçirebilir.

    3. Pilot proje bir başarısızlıktı ve analizi, pilot projenin yetersiz seçimi, yetersiz eğitim ve kaynak eksikliği gibi sorunları ortaya çıkardı. Bu durumda, yeniden pilot uygulamaya mı, uygulamaya devam etmeye mi yoksa CASE araçlarını terk etmeye mi karar vermek oldukça zor olabilir. Ancak, ne olursa olsun karar uygulama sürecinin gözden geçirilmesi ve dikkatin artırılması gerekmektedir.

    4. Pilot proje başarıyla tamamlandı ve CASE araçlarının bazı departmanlarda veya belki de tüm organizasyonda uygulanmasının faydalı olduğu düşünülüyor. Bu durumda bir sonraki adım en uygun uygulama ölçeğinin belirlenmesidir.

    Bazı durumlarda, bir pilot projenin analizi başarısızlığa birden fazla faktörün katkıda bulunduğunu gösterebilir. CASE teknolojisini uygulamaya yönelik müteakip girişimler, başarısızlığın tüm nedenlerini açıkça tanımlamalıdır. Aşırı durumlarda, dikkatli analizler şunu gösterebilir: şu anda kuruluş, karmaşık CASE araçlarını başarıyla uygulamaya hazır değildir. Böyle bir durumda örgüt, sorunlarını başka yollarla çözmeye çalışabilir.

    Pilot projenin özellikleri. Başarı için kritik olan unsurları ve bu unsurların organizasyonun bütününü ne ölçüde yansıttığını belirlemek için pilot projenin analiz edilmesi çok önemlidir. Örneğin, kuruluştaki en iyi programcılar bir pilot projede yer alıyorsa, CASE araçlarının kullanılmasına rağmen başarılı olabilir, onlar sayesinde değil. Öte yandan, CASE araçları, özelliklerine açıkça uygun olmayan bir uygulama geliştirmek için kullanılabilir. Bununla birlikte, böyle bir kullanım, belirli bir kuruluşta fonların en rasyonel kullanım alanını gösterebilir.

    Pilot projenin, organizasyonu bir bütün olarak temsil etmeyen en önemli özelliklerini not edelim:

    Bir pilot projedeki süreçler, organizasyonun tamamındaki süreçlerden biraz farklıdır;

    Pilot proje ekibinin nitelikleri, organizasyonun geri kalanının niteliklerini yansıtmaz;

    Projeye tahsis edilen kaynaklar projeye tahsis edilenlerden farklı olabilir. düzenli projeler;

    Bir projenin konu alanı veya kapsamı diğer projelerden farklılık gösterebilir.

    CASE araçlarını kullanmanın avantajlarından yararlanın. Pilot projenin sonuçları, bir bütün olarak organizasyonun yetenekleri ile karşılaştırılmalıdır. Örneğin, en motive ve yetenekli proje katılımcıları ciddi alım zorlukları yaşıyorsa, diğer departmanlardan daha az motive ve yetenekli programcıların önemli ölçüde daha fazla eğitime ihtiyacı olacaktır.

    Bir pilot proje, fonların bazı proje sınıfları için uygun olduğunu ve diğerleri için uygun olmadığını da gösterebilir. Örneğin, resmi bir doğrulayıcı hayati uygulamalar için uygun olabilir ve daha az kritik uygulamalar için uygun olmayabilir.

    Bir geçiş planı geliştirmeden önce, bir kuruluş farklı departmanlar veya proje sınıfları için beklenen etkiyi değerlendirmelidir. Ancak, bazı departmanların CASE araçlarını kullanmak için gerekli niteliklere veya kaynaklara sahip olmayabileceğini unutmayın.

    Uygulama karar seçenekleri. Olası bir çözüm aşağıdakilerden biri olmalıdır:

    Ek bir pilot proje çalıştırın. Bu seçenek yalnızca, bir CASE aracının bir kuruluşta uygulanmasıyla ilgili çözülmemiş belirli sorunlar varsa dikkate alınmalıdır. Yeni pilot proje bu sorulara cevap verecek şekilde tasarlanmalıdır.

    Fonları reddet. Bu durumda, belirli bir tesisi reddetme nedenleri, kuruluşun karşılanmamış ihtiyaçları veya kriterleri açısından tanımlanmalıdır. CASE araçlarının uygulanmasına geçmeden önce, kuruluşun gereksinimlerinin geçerliliği gözden geçirilmelidir.

    Genel olarak CASE araçlarını kullanmayı reddedin. Bir pilot proje, bir kuruluşun CASE araçlarını uygulamaya hazır olmadığını veya yazılım oluşturma ve sürdürme sürecinin bu yönünü otomatikleştirmenin kuruluş üzerinde herhangi bir etkisinin olmadığını gösterebilir. Bu durumda, azalan CASE tesislerinin nedenleri, karşılanmayan kurumsal ihtiyaçlar veya kriterler açısından da tanımlanmalıdır. Aynı zamanda, belirli bir aracın eksiklikleriyle ilişkili olarak bu seçenek ile önceki arasındaki farkı anlamak gerekir. Bu aşamanın çıktısı, pilot projenin sonuçlarını tartışan ve uygulama kararlarını detaylandıran bir belgedir.

    VAKA ARAÇLARININ PRATİK UYGULAMASI

    CASE araçlarının pratik kullanımına geçiş süreci, bir geçiş planının geliştirilmesi ve ardından uygulanmasıyla başlar. Bu plan, dikkatle seçilmiş bir pilot projeden, çok çeşitli özellik çeşitliliğine sahip projelere aşamalı bir geçiş yaklaşımını yansıtabilir.

    Bir geçiş planının geliştirilmesi

    Geçiş planı şunları içermelidir:

    Planın uygulanmasıyla ilgili hedefler, değerlendirme kriterleri, program ve olası riskler hakkında bilgi;

    Aracı satın alma, yükleme ve yapılandırma hakkında bilgiler;

    Aracın entegrasyonu ile ilgili bilgiler mevcut araçlar ve hem CASE araçlarının birbirleriyle entegrasyonu hem de bunların kuruluşta mevcut olan yazılımın geliştirme ve işletim süreçlerine entegrasyonu dahil olmak üzere süreçler;

    Geçiş sürecinin tamamlanması sırasında ve sonrasında kullanılan öngörülen eğitim ihtiyaçları ve kaynakları;

    Fonların kullanımına ilişkin standart prosedürlerin belirlenmesi.

    Geçiş planıyla ilişkili hedefler, değerlendirme kriterleri, program ve riskler. Bu konulara ilişkin bilgiler aşağıdakileri kapsamalıdır:

    Aracın nihai olarak kullanılacağı proje türleri;

    Aracın bireysel projelerde pratik kullanımına geçiş programı;

    Gerekli eğitim de dahil olmak üzere, kullanıcı sayısı açısından aracın uygulama programı;

    Olası riskler ve öngörülemeyen durumlar;

    Fon kullanımının neden olduğu değişiklikleri değerlendirmek için mevcut (referans) veri ve ölçüm kaynakları.

    Yukarıdakilere ek olarak, değişiklik kontrolü konularına özel dikkat gösterilmelidir. Teknoloji kuruluş genelinde geniş çapta yaygınlaştırılacağından, üst yönetimin, değişim aracılarının ve hedeflerin rolleri pilot projeyle karşılaştırıldığında netleştirilmelidir.

    Tesisin kullanımını desteklemek için daha fazla özel destek planlaması gerekmediğinde geçiş planının başarıyla tamamlandığı varsayılır. Bu noktada, aracın kullanımı, ondan beklenenle tutarlıdır ve araçla çalışma planı, Genel Plan kuruluşta mevcut olan mevcut yazılım desteği.

    Araçların satın alınması, kurulması ve yapılandırılması. Bir pilot proje kapsamında yürütülen bu süreçler tüm organizasyon için gerekli olabilir. Bu, aşağıdakilerle ilgili bilgileri gerektirir:

    Her bir platform için satın alınması gereken yazılım bileşenleri ve dokümantasyon setleri;

    Gerekli eğitim;

    Yeni sürümler elde etme mekanizması;

    Kuruluştaki mevcut prosedürleri ve anlaşmaları takip etmek için aracı özelleştirme;

    Aracın kurulmasından, entegre edilmesinden, yapılandırılmasından ve çalıştırılmasından sorumlu bir kişinin veya departmanın varlığı;

    Veri dönüştürme ve hizmetten çıkarma planı.

    Edinme, kurulum ve yapılandırma görevleri, pilot proje ekibinden kuruluşun mevcut yazılım sistemleri destek ekibine mümkün olan en kısa sürede aktarılmalıdır.

    Aracı mevcut araçlar ve süreçlerle entegre edin. Bu, aracın tam olarak uygulanmasında önemli bir adımdır. Çoğu durumda, bu entegrasyon pilot tasarım sürecinde gerçekleştirilmez, ancak bu sırada elde edilen bilgiler entegrasyon planlarının geliştirilmesine yardımcı olabilir. Entegrasyon planlaması için aşağıdaki bilgiler gereklidir:

    Yeni aracın entegre olması gereken mevcut araçların adları ve sürümleri;

    Yeni ve mevcut araçlar tarafından paylaşılacak verilerin açıklamaları ve bu verilerin kaynakları hakkında ön bilgiler;

    Yeni ve mevcut araçlar arasındaki diğer ilişkilerin açıklamaları (kontrol ve kullanım ilişkilerinin devri gibi) ve bu ilişkileri destekleyen mekanizmalar hakkında ön bilgiler;

    Entegrasyonla (ve muhtemelen mevcut araçlardan ve verilerden geçişle) ilişkili maliyet, zaman çizelgesi ve risk tahminleri;

    Mevcut süreçleri iyileştirmeye yönelik faaliyetlerde bu aracı uygulama yollarının açıklaması;

    Yeni aracın kullanımından kaynaklanan ve mümkün olduğu kadar sayısal olarak mevcut süreçlerde ve ürünlerde beklenen değişiklikler.

    Araç değerlendirme ve seçim sürecinde entegrasyon ihtiyaçları dikkate alınırsa, yeni bir aracın ve mevcut araç ve süreçlerin entegrasyonu ile ilgili risk azalır.

    Geçiş sürecinin tamamlanması sırasında ve sonrasında kullanılan eğitim ve kaynaklar. Bu konulara ilişkin bilgiler aşağıdakileri kapsamalıdır:

    Aracın nasıl kullanılacağı konusunda eğitime ihtiyaç duyan personel (kullanıcılar, yöneticiler ve entegratörler dahil);

    Çeşitli araçların ortak kullanımına yönelik eğitimin özel önemi ve bu araçlarla ilgili yöntemler ve süreçler dikkate alınarak, her bir kullanıcı ve servis personeli kategorisi için gereken eğitim türü;

    Farklı profesyoneller için gereken eğitim türü (örneğin, test ekibi ve bağımsız sertifika yetkilisi için);

    eğitim sıklığı;

    Destek türleri ve kullanılabilirliği.

    Fonların kullanımına ilişkin standart prosedürlerin belirlenmesi. Geçiş planı, fonların kullanımına yönelik ilk başvuru uygulamalarını ve prosedürlerini tanımlamalıdır. Olası başvuru türleri ve prosedürler şunları içerir:

    Fonların kullanımına ilişkin standartlar;

    Modelleme ve Tasarım Kılavuzları;

    Adlandırma kuralları;

    Muayene programları ve kullanılan metodolojiler dahil olmak üzere kalite kontrol prosedürleri ve kabul süreçleri;

    Yedekleme prosedürleri, ana kopya koruması ve veritabanı yapılandırması;

    Mevcut araçlar ve veritabanları ile entegrasyon prosedürleri;

    Veri paylaşımı ve veri tabanı bütünlük kontrolü için prosedürler;

    Güvenlik standartları ve prosedürleri;

    Dokümantasyon standartları.

    Pilot proje sırasında geliştirilen CASE araç kullanım standartları, kuruluş için daha eksiksiz bir araç kullanım standartları seti geliştirmek için bir başlangıç ​​noktası olarak kullanılmalıdır. (santimetre. saniye 1.3). Bu, pilot projedeki katılımcıların deneyimlerini dikkate almalıdır.

    Geçiş planının uygulanması

    Bir geçiş planının uygulanması, CASE araçlarının kullanımının sürekli olarak izlenmesini, sürekli destek sağlanmasını ve gerektiğinde araçların bakımını ve güncellenmesini gerektirir.

    Periyodik incelemeler. Elde edilen sonuçlar programa uygun olarak periyodik olarak gözden geçirilmelidir. Geçiş planı gerektiği gibi ayarlanmalıdır. Kuruluşun ihtiyaçlarının ne ölçüde karşılandığı ve CASE araçlarının başarılı bir şekilde uygulanması için kriterlere sürekli dikkat gösterilmelidir.

    Periyodik gözden geçirmeler, uygulama süreci tamamlandıktan sonra da devam etmelidir. Bu tür incelemeler, gerekli işlevleri yerine getirmeye ne kadar iyi devam ettiklerini belirlemek için CASE araçlarıyla çalışırken elde edilen ölçümleri ve diğer bilgileri analiz edebilir. İncelemeler, ek işlem değişikliklerine duyulan ihtiyacı da gösterebilir.

    Mevcut destek. CASE araçları için mevcut destek kaynaklarının belirlenmesi gereklidir. Bu tür bir destek şunları sağlamalıdır:

    Fonların kullanımı ile ilgili soruların cevaplanması;

    hakkında bilgi aktarımı ilerlemek ve organizasyondaki diğer profesyonellere öğrenilen dersler;

    Aracın kullanımına ilişkin standartların, anlaşmaların ve prosedürlerin değiştirilmesi ve iyileştirilmesi;

    Yeni araçların mevcut araçlarla entegrasyonu ve yeni sürümler çıktıkça entegre araçların bakımı;

    Yeni işe alınanlara fonların alınmasında ve ilgili prosedürlerde yardımcı olmak;

    Sürüm yükseltmelerinin planlanması ve kontrolü;

    Araçların yeni özelliklerinin organizasyonel süreçlerde tanıtılmasının planlanması.

    yeni oyuncu 24 Mart 2009, 19:35

    Bir CASE Aracı Seçmek: Kriterler ve Karşılaştırma Yöntemleri

    • Kereste odası *

    Bugün, CASE aracının amaç ve hedeflerini en uygun ve tam olarak tatmin edici seçme sorunu, geniş çeşitlilikleri ve geliştiricinin ihtiyaçları karşılamak için sunmaya hazır olduğu çok çeşitli çözümler göz önüne alındığında en alakalı gibi görünüyor. otomasyon. Bu makalenin amacı, mevcut araçlara aşina olmanın yanı sıra karşılaştırmalı bir analiz için en önemli kriterleri vurgulamaktır.

    Tasarım Yaklaşımları

    Bir CASE aracının seçimi büyük ölçüde IS tasarımına özel yaklaşıma bağlıdır. Yaklaşımların en önemlileri yapısal (işlevsel), nesne yönelimli olup, ARIS metodolojisi de ayrı ayrı vurgulanmıştır.
    IS'nin geliştirilmesine yönelik yapısal yaklaşımın özü, otomatik işlevlere ayrışmasında yatmaktadır: sistem, sırasıyla alt işlevlere ayrılan, görevlere bölünmüş vb. olan işlevsel alt sistemlere bölünmüştür. Bugüne kadar, aşağıdakiler yaygın olarak kullanılmaktadır:
    • CA ERwin Süreç Modelleyici (eski adıyla: BPwin)
    • CA ERwin Veri Modelleyici (eski adıyla: ERwin)
    Nesne yönelimli yaklaşım, nesne ayrıştırmayı kullanırken, sistemin statik yapısı nesneler ve aralarındaki ilişkiler açısından, sistemin davranışı ise nesneler arasındaki mesaj alışverişi açısından tanımlanır. Nesne yönelimli yaklaşımı karşılayan araçlar:

    ARIS metodolojisi, kuruluşların faaliyetlerinin çeşitli yönlerinin modellenmesi için ilkeleri tanımlar, iş süreçlerine bütünsel bir bakış sunan entegrasyon kavramına dayanır ve tek bir sistem yaklaşımı içinde entegre edilmiş farklı metodolojiler kümesidir. Grafiksel olarak, bu yaklaşım aşağıda sunulmuştur:

    Fon karşılaştırması

    CASE araçlarını karşılaştırma kriteri olarak şunları ayırmanız önerilir: iş süreçlerinin derinlemesine kapsamlı bir analizini yapma olasılığı, kullanılan modellerin tanımının ve netliğinin eksiksizliği, esneklik, kullanılan aracın adaptasyon derecesi belirli sorunları çözmenin yanı sıra, program kodu oluşturma olasılığı ve araçların yaygınlık oranı yaklaşımı ele alınmaktadır.

    Ele alınan yaklaşımların seçilen kriterlere göre karşılaştırılması

    Rusya'daki en popüler CASE araçlarının karşılaştırılması

    Arasında bireysel özellikler araçların her biri karakterize edilebilir: tasarım bilgilerini Silverrun için harici dosyalara üç şekilde verme yeteneği, Westmount - Vantage Team Builder'dan aracın basamaklı modeline yönlendirme, bu araç Uniface ile etkileşime girdiğinde hızlı prototipleme avantajı . Oracle'ın (Tasarımcı/Geliştirici) araçları, yaşam döngüsü için tam destek sağlar. Yerli otomasyon araçları olan ERwin ve BPwin basitleştirilmiş ve hedeflenmiş bir yapıya sahip oldukları için en basit ve kullanışlı otomasyon çözümlerinden biri olarak karşımıza çıkmaktadır. Rational Rose gibi nesne yönelimli araçlar, grup çalışması için açık ara en uygun araçlardır.

    Ürünlerin karşılaştırılması sonucunda, yapısal yaklaşımı karşılayan araçların (ERwin, BPwin) ağırlıklı olarak IP gereksinimlerinin belirlenmesi aşamalarında kullanıldığı sonucuna varabiliriz. Bu tür araçlar, söz konusu süreçlerin derinlemesine analizi için uygundur (Vantage Team Builder), bireysel yazılım bileşenlerinin bağımsızlığı nedeniyle (Oracle) kaynakların en verimli şekilde kullanılmasına izin verir. Nesne yönelimli araçlara gelince, uygulama metodolojisinin, Rational Rose ve Power Designer içinde kullanılan ve oldukça kullanışlı olan UML dilinin evrenselliği ve netliği aracılığıyla herhangi bir türü tasarlamanıza izin verdiğini belirtmekte fayda var. herhangi bir eğitim düzeyindeki işletme uzmanları için bir araç.

    Analiz ve tasarım aşamasında (yukarıdaki analize uygun olarak) iş süreçlerinin modellenmesi sorununun çözümüne ilişkin yaklaşımların konumlandırılması da aşağıdaki gibi gerçekleştirilebilir:

    Sonuç olarak, UML standardının yayılması nedeniyle, belki de şimdi böyle bir analizin artık birkaç yıl önceki kadar alakalı görünmediğini söylemek istiyorum. Bununla birlikte, belirli bir tasarım metodolojisi bağlamında belirli araçların artılarını ve eksilerini oldukça açık bir şekilde yansıtır.

    Etiketler: CASE araçları, CASE, tasarım, yaklaşım, metodoloji, bilgi sistemleri, analiz, karşılaştırma, kriterler