Sistem Geliştirme Yaşam Döngüsünde İlk 11 Aşama

Bu makale, sistem geliştirme yaşam döngüsünün on bir aşamasına ışık tutmaktadır. Aşamalar: 1. Alan Seçimi ve Problem Tanımı (Ön İnceleme) 2. Veri / Bilgi Toplama 3. Alternatiflerin Yaratılması 4. Fizibilite Çalışması 5. Master Geliştirme Planı 6. Ekipman Değerlendirme ve Seçme 7. Sistem Tasarımı ve Geliştirme 8. Sistem Test 9. Sistem Uygulaması 10. Sistem İnceleme ve İzleme.

Sistem Geliştirme Yaşam Döngüsü Aşama # 1. Alan Seçimi ve Problem Tanımı (Ön Araştırma):

Bu ilk aşamadır ve ilgili alanın kısa bir incelemesinden oluşur ve projenin bir sonraki aşamaya alınması, gelişimin bir süre ertelenmesi veya başka bir işlem yapılmamasını tavsiye etmesiyle sonuçlanacaktır.

Bazen, daha detaylı bir fizibilite çalışmasının ardından bir ön incelemeye (ilk çalışma) ayrılır.

Aşama, iş ortamındaki değişiklikler veya beklenen şampiyonlar, mevcut sistemlerin başlatılması veya başarısızlığı veya rakiplerin geliştirmekte olduğu belirli sistemlerde yer alan belirli alanla ilgili teknolojik gelişmelerin farkındalığı nedeniyle ihtiyacı algılayan yönetim tarafından başlatılır.

Sistem Geliştirme Yaşam Döngüsü Aşama # 2. Veri Toplama:

Veri toplama, sistemler projesine uygun bilgilerin toplanmasını ifade eder. Bilgi edinmek için, analist kitap veya rapor okuyabilir, kayıtlara gidebilir, daha sonra analiz için formlar toplayabilir veya insanlarla röportaj yapabilir. Görüşme, yöneticiler, işçiler, hatta bazen müşterilerle görüşebilecek analist için önemli bir beceridir.

Çoğu zaman, en önemli bilgilerin bazıları düşük seviyeli çalışanlardan (çalışanlar) gelir.

Bilgi kaynakları:

Bilgi iki ana kaynaktan toplanır. Kaynaklar aşağıdaki gibidir:

1. Kuruluşun ortamından.

2. Kurum içindeki personel veya yazılı belgeler.

Birincil dış kaynaklar:

1. Hükümet belgeleri

2. Satıcılar

3. Gazeteler ve meslek dergileri.

Birincil iç kaynaklar:

1. Personel personeli

2. Finansal raporlar

3. Kılavuzların sistem dokümantasyonu

4. Raporlar ve işlem belgeleri

5. Profesyonel personel (hukuk danışmanı, EDP (elektronik veri işleme) denetçisi vb.

6. Kullanıcı personeli.

Donanım satıcıları, sistem ve yazılım hakkında bilgi kaynağıdır. Piyasada sorunlu alanı korumak için binlerce yazılım paketi vardır ve bu yazılımlar makul değişikliklerden sonra kullanılır. Bu paketlerin bilgileri zaten donanım satıcıları tarafından satılmaktadır.

İkinci diğer dış bilgi kaynağı ise devlet belgeleri, teknik gazeteler ve meslek dergileridir. Yeni donanımlar, donanım donanımları, yazılım geliştirmeleri vb. Hakkında haftalık bilgi sağlarlar.

İç bilgi kaynakları kullanıcı personeli veya kullanıcı ile sınırlıdır. Kullanıcı personelinin bilgileri çok geniştir, yıllardır kullanıcı alanında olan ve mevcut faaliyetler ve uygulamalar hakkında bilgi sahibi olan kilit çalışanlardır, daha sonra tarihsel ve hassas belgelerden bilgi toplarız.

Bazı durumlarda, analist için mevcut olan tek kaynak budur. Bilgi toplanırken, analist önemli hususları belgeleyecek, böylece daha sonra atıfta bulunabilecek. Bu amaçla formları, çizelgeleri veya tabloları kullanabilir.

Gerçekleri elde etmenin temel yöntemleri şunlardır:

(a) Görsel ve fotoğrafik yöntemler de dahil olmak üzere çeşitli şekillerde gerçekleştirilebilecek faaliyetleri gözlemlemek.

(b) Anket kullanımı veya inceleme ve inceleme ile.

Sistem Geliştirme Yaşam Döngüsü Aşama # 3. Alternatiflerin Yaratılması:

Bir kez, analist sorunları hakkında net bir fikir sahibi, bazı olası çözümler yaratmaya başlar. Gerçek uygulamada, bu çözümler genellikle ilk araştırma (veri toplama) devam ederken oluşmaya başlar. Ardından, araştırmayı tamamladıktan sonra, analist en umut verici alternatifleri seçer ve geliştirir.

Sağlam alternatifler oluşturabilmek için analistin geniş bir geçmişe sahip olması, soruna uygulanabilecek birçok farklı ekipman tipini bilmesi ve kullanılabilecek çeşitli prosedür türlerini bilmesi gerekir.

Bu arka plandan, başka bir şirketin veya grubun kullandığı birine benzer bir alternatif geliştirebilir veya şirketinin sorununa özel veya benzersiz bir çözüm oluşturabilir.

Bu aşamadaki çözümlerin ayrıntılı olarak geliştirilmediğinin farkına varmak önemlidir. Burada geliştirilen prosedürler spesifik değildir. Her alternatif için genel bir mantık akışı oluşturulmuş olmasına rağmen, sistem tasarım aşamasında özel adımlar belirlenecektir.

Sorun oldukça sınırlı olmadığı sürece, analistler birden fazla alternatif geliştirmeye çalışmalıdır. Bu, onlara yalnızca hızlı ve açık olanı konuşmak yerine yaratıcı çözümleri keşfetme özgürlüğü verecektir. Aynı zamanda yönetime mevcut çözümler yelpazesi hakkında daha geniş bir perspektif verecektir.

Sistem Geliştirme Yaşam Döngüsü Aşaması # 4. Fizibilite Çalışması:

Alternatifler öğrenildikten veya tasarlandıktan sonra, analist fizibilite çalışmasını yapar.

Fizibilite çalışmasının yapılması aşağıdaki adımları içerir:

(a) Sorunların amaçları hakkında bir açıklama oluşturmak.

(b) Veri toplama, veri sunumu, gerekli dosya ve kayıtların listesi, iletişim gereksinimleri, akış şemalarının hazırlanması ve maliyet tahminlerini içeren mevcut sistemin analizi.

(d) Ana çıktı gereksinimlerinin belirlenmesi.

(e) Şirket operasyonları üzerindeki etkileri incelemek.

(f) Finansal etki.

(g) Sistemin benimsenmesinden kaynaklanan maddi olmayan kayıplar ve faydaların özeti.

(h) Devam etmek için bir öneri.

Ön inceleme sırasında ortaya çıkan veri toplama sistemi fizibilitesini, sistemin kuruma yararlı olabileceği ihtimalini incelemektedir.

Dört fizibilite testi:

1. Operasyonel Test

2. Ekonomik Test

3. Teknik Test

4. Siyasi Test

1. Operasyonel Test:

Önerilen projeler elbette sadece kuruluşun işletme gereksinimlerini karşılayacak bilgi sistemlerine dönüştürülebilirlerse faydalıdır. Basitçe ifade etmek gerekirse, bu fizibilite testi, sistemin geliştirilip kurulduğunda çalışıp çalışmayacağını sorar. Uygulamanın önündeki başlıca engeller var mı? Aşağıdaki sorular bir projenin operasyonel uygulanabilirliğini test etmeye yardımcı olur.

Mevcut işletme yöntemleri kullanıcılar tarafından kabul edilebilir mi? Olmazlarsa, kullanıcılar daha operasyonel ve kullanışlı bir sistem ortaya çıkaran bir değişiklikten memnuniyet duyabilirler. Proje için yönetimden yeterli destek var mı? Kullanıcılardan mı? Mevcut sistem, kişilerin değişimin nedenini görmeyeceği ölçüde çok beğenilir ve kullanılırsa, direnç olabilir.

Önerilen sistem zarar verebilir mi? Aşağıdaki sorular bu konuyla ilgilidir:

(a) Kontrol kaybı herhangi bir alanda sonuçlanabilir mi?

(b) Müşteriler istenmeyen bir şekilde etkilenecek mi?

(d) Sistem herhangi bir açıdan veya alanda daha zayıf sonuçlar üretecek mi?

(e) Bilginin erişilebilirliği kaybolacak mı?

4. Kullanıcılar projenin planlanması ve geliştirilmesinde rol aldı mı? Erken katılım, sisteme karşı direnç ve genel olarak değişim şansını azaltır ve başarılı projelerin olasılığını arttırır.

Operasyonel fizibilite, insanların sistemle nasıl çalışabileceğinin bir ölçüsüdür. Örneğin, bir sistem yöneticilerin verilere erişmek için BASIC, COBOL veya FORTRAN programları yazmasını gerektirebilir. Bununla birlikte, yönetici muhtemelen programların bunları çözmek için nasıl inşa edileceğine değil, çözülmesi gereken sorunlara odaklanabildikleri zaman sistemden en büyük yardımı alır.

2. Ekonomik Test:

Fayda ve maliyetlerin tahmin edilmesini içerir. Bu fayda ve maliyetler maddi veya maddi olmayan olabilir.

Teknik olarak geliştirilebilecek ve kurulduğunda kullanılacak bir sistem hala iyi bir yatırım olmalıdır. Diğer bir deyişle, finansal faydalar finansal maliyetlere eşit veya fazla olmalıdır.

Ön araştırma sırasında analistler tarafından ortaya çıkan ekonomik ve finansal sorular, aşağıdakilerin tahminlerini ister:

1. Düşünülen uygulama sınıfı için donanım ve yazılım maliyeti.

2. Hiçbir şeyin değişmemesi durumunda maliyet (sistem geliştirilmez).

3. Tam bir sistem soruşturması yürütmenin maliyeti.

4. Düşük maliyet ya da daha az maliyetli hata şeklinde sağlanan faydalar.

Her bir projedeki maliyet ve fayda tahminleri, hangi projelerin en çok dikkate alınmaya değer olduğunu belirlemek için bir temel sağlar. Her bir tahmin, maliyetlerin faydalarla ne kadar hızlı bir şekilde geri kazanıldığını belirlemek, hem mutlak hem de faiz ayarlı aşırı fayda miktarlarını hesaplamak ve faydaların maliyetlere oranını belirlemek için analiz edilebilir.

Bu faktörlerin tümü, projenin ekonomik uygulanabilirliği hakkında genel bir fikir edinirken dikkate alınır.

Uygulanabilir olmak için, bir proje teklifi tüm bu testleri geçmelidir. Aksi takdirde, uygulanabilir bir proje değildir. Örneğin, finansal olarak uygun ve operasyonel açıdan çekici olan, gerekli teknoloji yoksa ya da makul bir maliyetle geliştirilebilecek, ancak hangi hemşirelerin kullanmaktan kaçınacağı, operasyonel olarak uygulanabilir olduğu düşünülen bir tıbbi sistem mümkün değilse, personel kayıt sistemi mümkün değildir.

Sistem Geliştirme Yaşam Döngüsü Aşama # 5. Master Geliştirme Planı:

Sistem geliştirme çabasının bir nevi mavi baskısıdır. Dinamik bir organizasyonda, bir seferde ele alabilen ve bir tahsis işlemi gerektiren bilgisayar işleme uygulamaları için daha fazla fırsat vardır. Bu nedenle, ana geliştirme planı gereklidir. Bilgisayarlaştırılacak çeşitli uygulamaların bir çizelgesidir.

Böyle bir plan aşağıdaki dört aşamadan oluşur:

1. Önerilen sistemlerin geliştirme çabalarının hedefleri analist tarafından ortaya çıkarılmıştır.

2. Kuruluşun mevcut yetenekleri analist tarafından değerlendirilir. Bu değerlendirme mevcut ekipmanı, yazılım uygulamalarını ve kişisel harcamaları, tesis kullanımını kapsayacaktır.

3. Analist, bilgisayar donanımındaki olası teknolojik gelişmeleri gözden geçirir.

4. Son olarak, analist bir donanım ve yazılım programı, yazılım bakım ve dönüştürme çalışmaları uygulama geliştirme programı, personel kaynakları planı ve finansal kaynaklar planını içeren özel bir plan hazırlar.

Master geliştirme planı temel olarak bilgisayarlaştırılacak çeşitli uygulamaların bir çizelgesidir, yani sistemlerin analiz, tasarım, uygulama ve bakım faaliyetlerinin başlangıç ve bitiş tarihlerinden oluşur. Bu program İnsan gücü, donanım ve finansal programlar tarafından desteklenmektedir.

Sistem Geliştirme Yaşam Döngüsü Aşama # 6. Ekipman Değerlendirme ve Seçme:

Bu aşamada, sistem departmanı, belirli makinelerle ilgili bilgi ve fiyatlar için ekipman satıcılarıyla iletişim kurabilir. Bir sistemin teklifi büyük ekipman alımları içerdiğinde, sistem geliştirmenin bu aşaması başlı başına büyük bir proje olabilir

Makinelerin, sistemlerin teklifinde belirtilen sınırlar dahilinde bir fiyata satın alınmaları, kiralanmaları veya kiralanmaları durumunda, proje teklif edildiği gibi devam eder. Aksi takdirde, analist beklenmedik durumdaki fizibilite ve sistemlerin teklif aşamalarına geri dönmeye zorlanabilir maliyet verileri.

Bununla birlikte, iyi bir analist, maliyet projeksiyonlarının makul olduğundan emin olmak için fizibilite analizi sırasında birkaç tedarikçiyle fiyatları ve kapasiteleri kontrol edecektir. Çalışmanın sadece maliyetini değil, aynı zamanda büyük olasılıkla fiyatı da göz önünde bulundurur.

Sistem Geliştirme Yaşam Döngüsü Aşama # 7. Sistem Tasarımı ve Geliştirme:

Bir bilgi sisteminin tasarımı, bir sistemin sistem analizi sırasında belirlenen gereksinimleri nasıl karşılayacağını belirten detayları üretir. Genellikle sistemler, uzmanlar bu aşamayı, fiziksel tasarım olarak adlandırılan program yazılımının geliştirilmesinin aksine, mantıksal tasarım olarak adlandırır.

Sistem teklifi kullanıcı tarafından kabul edilir edilmez, sistem spesifikasyonunu hazırlamak için çalışma başlayabilir. Bu aşama, kabul edildiği şekilde gereklilikleri alır ve teklifin hazırlanmasına yol açan ve sistemi programlama yoluna hazırlamak için gerekli detay seviyesine kadar geliştiren çalışma.

Bu noktada analist, girdi ve çıktıların detayı, gereken işlem ve sistemin günlük olarak nasıl çalışacağı ile ilgilenir.

Sistemin karmaşıklık seviyesine ve yapılan işin miktarına ve kalitesine bağlı olarak, daha önceki aşamalarda, bu aşama aylarca süren çok uzun sürebilir.

Sistemin bilgisayar odaklı tasarımı - giriş işlemlerinin detayı, basılı raporların detayı, ekranlar ve diğer çıktılar, dosya veya veritabanı yapısı, kayıtların içeriği, gereken işlemler ve gereken verim ile ilgilidir. bir bilgisayar işleme açısından sistem.

Sistem analistleri, sistemin üreteceği raporları ve diğer çıktıları tanımlayarak başlar. Ardından, her biri hakkındaki veriler, kağıdın, ekranın veya diğer ortamın tam konumu da dahil olmak üzere tam olarak işaretlenir. Genellikle tasarımcılar, formu tamamlar veya sistemin tamamlandığında görünmesini bekledikleri ekranı görüntüler.

Sistem tasarımı ayrıca girilecek, hesaplanacak veya saklanacak verileri açıklar. Bireysel veri kalemleri ve hesaplama prosedürleri ayrıntılı olarak yazılmıştır. Tasarımcılar manyetik disk, manyetik bant ve hatta kağıt dosyalar gibi dosya yapılarını ve depolama aygıtlarını seçer. Yazdıkları prosedürler verilerin nasıl işleneceğini ve çıktıların nasıl üretildiğini anlatır.

Tasarım spesifikasyonlarını içeren dokümanlar, tasarıma tasvir etmek için birçok farklı yol kullanır - grafikler, tablolar ve özel semboller. Ayrıntılı tasarım bilgisi programlama ekibine iletilir ve böylece yazılım geliştirme başlayabilir.

Tasarımcılar, programcılara, yazılımın ne yapması gerektiğini belirten eksiksiz ve net bir şekilde ana hatlarıyla belirtilen özellikleri sağlamaktan sorumludur. Programlama başlarken, tasarımcıların soruları cevaplamak, bulanık alanları netleştirmek ve tasarım özelliklerini kullanırken programcıların karşılaştığı sorunları ele almak mümkündür.

Tipik bir sistem spesifikasyonu şunları içerecektir:

1. Sistemde çalışan kontrollerin tanımı. Bu, girdi ve işleme üzerindeki kontrolü, erişim üzerindeki kısıtlamaları (örneğin, şifreler) ve çıktı üzerindeki kontrolü (örneğin, kontrollerin sayısını içerir) içerir.

2. Ayrıntılı bir geliştirme ve uygulama zaman çizelgesi. Bu bölüm, ayrı ayrı programlar da dahil olmak üzere, her bir görev arasındaki ilişkiyi ve her bir iş için planlanan başlangıç ve tamamlama verilerini gösteren tüm görevleri listelemelidir.

3. Bir yedekleme planı — Bu, sistemin esnekliğini sağlamak (örneğin, dupleksleme) ve sistemin bulunmaması durumunda sistemin alternatif bir yerde çalıştırılması için güvenlik önlemleri alınması için geliştirilecek prosedürleri tanımlamalıdır.

4. Belgenin alaka düzeyini ve önceki aşamalardan nasıl geliştiğini kapsayan bir giriş.

5. Girdi çıktılarının ve dosyalarının ayrıntılı açıklamaları, örneğin: belge düzenleri (giriş), ekran düzenleri, rapor düzenleri, dosya / kayıt düzenleri, veritabanı düzenleri.

6. Sistemin açıklaması. Bu genellikle eşlik eden akış şemaları, prosedür tabloları, veri akış şemaları veya veri modelleriyle birlikte anlatı formunda bir taslaktır.

7. İşlem gerekli. Bu aslında sistemdeki her programın ne yapması beklendiğini genel olarak belirleyerek ve ayrı olarak yayınlanan bireysel program spesifikasyonlarını destekleyerek ele alınabilir. Test için düzenlemeler de bu bölümde açıklanabilir.

8. Uygulama ile ilgili düşünceler — mevcut dosyaların dönüştürülmesi, paralel işlemlerin kontrol edilmesi, kullanıcı işlemlerinin üretimi ve bilgisayarla ilgili işlemlerin üretimi için düzenlemeler.

Bu aşamada, gerekli bilgisayar programlama çabası miktarının ilk güvenilir tahmininin üretilebilmesi mümkündür. Bu noktaya kadar tahminler büyük ölçüde bilgilendirilmiş tahminlerdir ve bu uygulamanın sonunda ortaya çıkan tahmin, daha önce mevcut olan tahminlere kıyasla oldukça korkutucu olabilir.

Bu, üst düzey yönetimin bu aşamada bir onay rolü almaya devam etmesini sağlamak için geçerli bir nedendir.

Artık üretilen tahminlerin sağlam bir temeli var ve eğer orijinal tahminlere göre büyük ölçüde değişkenlik gösteriyorsa, gelişimin uygulanabilirliğini gözden geçirmek için henüz çok geç değil.

Seçim şimdi arasında yatıyor.

1. Sistemi terk etmek

2. Planlandığı gibi devam etmek

3. Sistemi bir süre rafa koymak

4. Sistemin beklentilerini değiştirmek.

Bu seçeneklerin tümü bir kurum içi geliştirme için kullanılabilir, ancak bu aşamaya gelindiğinde, taahhüdün geri alınamaz olduğu genel olarak hissedilir. Bir dış tedarikçi söz konusu olduğunda, seçenek taraflar arasındaki sözleşmenin niteliği ile sınırlandırılabilir.

Değişken bir fiyat sözleşmesi, bu gibi durumlarda gözardı etmek için bir formül sağlamalıdır. Sabit bir fiyat düzenlemesi müşterileri yükselen fiyatlardan korur, ancak tahmin etmedeki önemli bir hata, tedarikçinin köşelerini kesmeye çalışmasına neden olabilir.

Sistem Geliştirme Yaşam Döngüsü Aşama # 8. Sistem Testi:

Sistem testinin amacı, tüm bireysel programların beklendiği gibi çalışmasını sağlamak, programların belirtilen gereklilikleri karşılamak için bir araya gelmelerini sağlamak ve bilgisayar sistemi ile ilgili büro ve diğer prosedürlerin birlikte çalışmasını sağlamaktır.

Sistem testinin ilk aşaması, hangi koşulların test edileceğini belirleyen, test verileri üreten, beklenen sonuçların bir çizelgesini üreten, testleri yapan ve bilgisayar tarafından üretilen sonuçları beklenen sonuçlarla karşılaştıran analistin sorumluluğudur.

Analist ayrıca prosedür testine de dahil olabilir. Analist sistemin düzgün çalıştığına memnun olduğunda, test için kullanıcılara teslim eder. Kullanıcı tarafından sistem testinin önemi vurgulanmalıdır. Sonuçta, sistemi doğrulaması ve devam etmesi gereken kullanıcıdır.

Test sırasında, yazılımın bozulmamasını, yani özelliklerine ve kullanıcıların çalışmasını beklediği şekilde çalışmasını sağlamak için sistem deneysel olarak kullanılır. Özel test verileri işleme için girdidir (test planı) ve beklenmeyen sonuçları bulmak için sonuçlar incelenir. Sınırlı sayıda kullanıcının da sistemi kullanmasına izin verilebilir, bu nedenle analistler beklenmedik şekillerde kullanmaya çalışıp çalışmadıklarını görebilir.

Kuruluşun sistemi uygulamadan ve buna bağlı olmadan önce bu sürprizleri bulmak tercih edilir. Birçok kuruluşta, testler orijinal programları yazanlar dışındaki kişiler tarafından yapılır, belirli parçaların nasıl tasarlandığını veya programlandığını bilmeyen kişilerin kullanılması, daha eksiksiz ve tarafsız testler ve daha güvenilir bir yazılım sağlar.

Sistem Geliştirme Yaşam Döngüsü Aşama # 9. Sistem Uygulaması:

Sistem test edildiğinde uygulama aşamasına geçmeye başlar. İdeal olarak, uygulama tamamlanmadan önce sistemin tamamlanması ve tam olarak test edilmesi gerekir, ancak bir paket kurulmadığı sürece bu nadiren olur. Normalde, gerçekleştiğinde, sistemin kurulması için gereken dosya parçaları ilk önce tamamlanır ve bu işlem devam eder.

Dönüştürme programları da dosyaları ayarlamak için başka bir sistemden veri kullanılmasına izin verecek şekilde mevcut olabilir. Bu veriler ayarlandıktan sonra, güncel tutulmalıdır ve bu nedenle ilk kullanım yeni sistemden yapılır. Bunu paralel bir süre izleyebilir ve ardından eski sistemi düşürmek için bir karar verilir.

Uygulamanın ilk aşaması başlar başlamaz - dosyalar başlar, tüm sistem dokümantasyonunun erişilebilir olması gerekir, viz. kullanım kılavuzu prosedür kılavuzları, bilgisayar kullanım talimatları ve güvenlik prosedürleri.

Sistem daha sonra geliştirme kadrosundan bilgisayar operasyon kadrosuna geçer ve sistem canlı hale geldiğinde, programcı, program ve dosyalara erişim konusunda sıkı prosedürler uygulanmalıdır. Kullanıcının isteğinden programcı tarafından uygulamaya kadar, sistem ve program değişikliklerine yönelik tüm talepleri kontrol etmek için prosedürler oluşturulmalıdır.

Uygulama, tamamlanmış ve test edilmiş donanım ve yazılım sistemini kullanıcıların fiili çalışma ortamına yerleştirmeyi içerir. Sistem personeli yeni ekipmanı kontrol edip kullanıma soktuğunda, kullanıcı personelini eğitir, yeni uygulamayı yükler ve kullanması gereken herhangi bir veri dosyasını oluşturur, bunun uygulandığını söylüyoruz.

Bu aşamada hem teknik hem de insan odaklı faaliyetler var. Teknik faaliyetlere örnek olarak veri dosyalarının dönüştürülmesi, eski programların yenileriyle değiştirilmesi ve bilgisayar işlemlerinin zamanlanması dahildir. İnsan odaklı etkinliklere örnek olarak oryantasyon, eğitim ve destek verilebilir.

Sistem Geliştirme Yaşam Döngüsü Aşaması # 10. Sistem İnceleme ve Takip:

Geliştirme veya uygulama sürecinin son aşaması, sistemin gözden geçirilmesi veya 'bazen denetim denir' olarak adlandırılır. Bu genellikle kullanıcı departmanından bir temsilciden, iç denetimden ve veri işlemden oluşan bir grup tarafından gerçekleştirilir. Temel amacı, sistemin belirlenmiş hedefleri karşılayıp karşılamadığını görmektir.

Bu, fiili maliyetlerin ve faydaların orijinal tahminlerle karşılaştırılmasını, sistemin genel olarak nasıl bir performans göstereceğini gözden geçirmeyi, değişiklik taleplerinin bir incelemesini ve dokümantasyon, kontrol ve güvenlik prosedürlerinin ve yedek düzenlemelerin incelenmesini içerecektir.

Gözden geçirme aşaması sistemin nasıl geliştiğini, sürecin nasıl yürüdüğünü inceler.

Aşağıdaki iki ana soru soruldu:

1. Sistemlerin kendisi uygun mu?

2. Sistem doğru bir şekilde geliştirildi mi?

Sistemin kendisinin uygun olup olmadığına karar vermek için, sisteme ihtiyaç duydukları bilgiyi doğru biçimde sağlayıp sağlamadığını bulmak için kullanıcıya danışılmalıdır. Sistemin doğru bir şekilde geliştirilip geliştirilmediğini belirlemek için, gözden geçirenler sistemin ne kadar iyi çalıştığını, programcının ve analistin sistemi geliştirmek için ne kadar zaman harcadığını ve sistem geliştirmenin programa göre tamamlanıp sonuçlanmadığını görebilir.

İlginç bir şekilde, bu başka bir projenin başlangıcını işaretleyebilir. Sistemdeki eksiklikler, başka bir yaşam döngüsüne yol açıyor, yorumcular kendilerini sordukça şöyle soruyor: “Değişiklikler faydalı mı? Neye benzemeliler? Nasıl yapılmalı, programlanmalı ve uygulanmalıdır? Doğru yapıldı mı? ”