Yazılım yaşam döngüsü. Aşamalar ve aşamalar. Yazılım yaşam döngüsü kavramı Yazılım yaşam döngüsü nedir

Yazılım yaşam döngüsü denilen süreci anlamadan yazılım geliştirme mümkün değildir. Ortalama bir kullanıcının bunu bilmesine gerek olmayabilir, ancak temel standartlara hakim olmanız tavsiye edilir (daha sonra bunun neden gerekli olduğu söylenecektir).

Biçimsel anlamda yaşam döngüsü nedir?

Herhangi bir şeyin yaşam döngüsü genellikle onun gelişim aşamasından ana kadar var olduğu süre olarak anlaşılır. tamamen reddetme seçilen uygulama alanında kullanımdan uygulamanın tamamen kullanımdan kaldırılmasına kadar.

Konuşuyorum basit bir dille Programlar, veritabanları ve hatta “işletim sistemleri” şeklindeki bilgi sistemleri, ancak sağladıkları verilerin ve fırsatların güncel olması durumunda talep görmektedir.

Yaşam döngüsü tanımının, operasyonda en kararsız olan beta sürümleri gibi test uygulamalarına hiçbir şekilde uygulanmadığına inanılmaktadır. Yazılımın yaşam döngüsünün kendisi birçok faktöre bağlıdır; bunların arasında ana rollerden biri programın kullanılacağı ortamın oynadığı ortamdır. Ancak şunu da vurgulamak mümkündür. Genel terimler Yaşam döngüsü kavramının tanımlanmasında kullanılır.

Başlangıç ​​gereksinimleri

• Sorunun formülasyonu;
• sistem için gelecekteki yazılımların karşılıklı gereksinimlerinin analizi;
• tasarım;
• programlama;
• kodlama ve derleme;
• test yapmak;
• hata ayıklama;
• Yazılım ürününün uygulanması ve bakımı.

Yazılım geliştirme yukarıda belirtilen aşamaların tümünü içerir ve bunlardan en az biri olmadan yapılamaz. Ancak bu tür süreçlerin kontrolü için özel standartlar oluşturulmuştur.

Yazılım Yaşam Döngüsü Süreç Standartları

Bu tür süreçlerin koşullarını ve gerekliliklerini önceden belirleyen sistemler arasında bugün yalnızca üç ana sistemi sayabiliriz:

• GOST 34.601-90;
• ISO/IEC 12207:2008;
• Oracle CDM'si.

İkinci uluslararası standart için bir Rus analogu var. Bu, sistem ve yazılım mühendisliğinden sorumlu olan GOST R ISO/IEC 12207-2010'dur. Ama yaşam döngüsü yazılım Her iki kuralda da tanımlanan , özü itibarıyla aynıdır. Bu oldukça basit bir şekilde açıklanmaktadır.

Yazılım türleri ve güncellemeler

Bu arada, şu anda bilinen çoğu multimedya programı için bunlar, temel yapılandırma parametrelerini kaydetmenin bir yoludur. Bu tür yazılımların kullanımı elbette oldukça sınırlıdır ancak aynı medya oynatıcılarla çalışmanın genel prensiplerini anlamaktan zarar gelmez. Ve bu yüzden.

Aslında, yazılımın yaşam döngüsünü yalnızca oynatıcının kendi sürümünü güncelleme veya codec bileşenleri ve kod çözücüleri yükleme düzeyinde içerirler. Ses ve video kodlayıcılar, herhangi bir ses veya video sisteminin ayrılmaz özellikleridir.

FL Studio'ya dayalı örnek

Başlangıçta, sanal stüdyo sıralayıcı FL Studio'ya Fruity Loops adı verildi. Yaşam döngüsü Yazılımın ilk değişikliğinin süresi dolmuş, ancak uygulama bir miktar dönüştürülmüş ve mevcut halini almıştır.

Yaşam döngüsünün aşamaları hakkında konuşursak, öncelikle sorunu belirleme aşamasında birkaç zorunlu koşul belirlendi:

• Yamaha RX gibi ritim makinelerine benzer bir bateri modülü oluşturmak, ancak stüdyolarda canlı olarak kaydedilen WAV formatında tek seferlik örnekler veya sekanslar kullanmak;
• entegrasyon işletim sistemi Pencereler;
• bir projeyi WAV, MP3 ve OGG formatlarında dışa aktarma yeteneği;
• Projelerin Fruity Tracks ek uygulamasıyla uyumluluğu.

Geliştirme aşamasında C programlama dili araçları kullanıldı. Ancak platform oldukça ilkel görünüyordu ve son kullanıcıya gerekli kalite ses.

Bu bağlamda, test ve hata ayıklama aşamasında, geliştiricilerin Alman Steinberg şirketinin yolunu takip etmesi ve ana ses sürücüsü gereksinimlerinde Tam Çift Yönlü mod desteğini uygulaması gerekiyordu. Ses kalitesi daha yüksek hale geldi ve tempoyu değiştirmenize, perdeyi değiştirmenize ve gerçek zamanlı olarak ek FX efektleri uygulamanıza olanak tanıyor.

Bu yazılımın yaşam döngüsünün sonu, atalarının aksine, sanal 64'te parametreleri düzenleme yeteneğine sahip tam teşekküllü bir sıralayıcı arayüzüne zaten sahip olan FL Studio'nun ilk resmi sürümünün piyasaya sürülmesi olarak kabul ediliyor. Sınırsız sayıda ses parçası ve MIDI parçası eklenebilir kanal miksaj konsolu.

Burada durmadı. Proje yönetimi aşamasında, bir zamanlar Steinberg tarafından geliştirilen VST formatındaki eklentilerin (önce ikinci ve ardından üçüncü versiyon) bağlanması için destek sağlandı. Kabaca söylemek gerekirse, VST ana bilgisayarını destekleyen herhangi bir sanal sentezleyici programa bağlanabilir.

Yakında herhangi bir bestecinin "donanım" modellerinin analoglarını, örneğin bir zamanlar popüler olan Korg M1'in tam ses setlerini kullanabilmesi şaşırtıcı değil. Üstelik. Addictive Drums veya evrensel Kontakt eklentisi gibi modüllerin kullanılması, profesyonel stüdyolarda tüm artikülasyon tonlarıyla kaydedilen gerçek enstrümanların canlı seslerinin yeniden üretilmesini mümkün kıldı.

Aynı zamanda geliştiriciler, Full Duplex modunun çok ötesinde olduğu ortaya çıkan ASIO4ALL sürücüleri için destek oluşturarak maksimum kaliteyi elde etmeye çalıştılar. Buna bağlı olarak bit hızı da arttı. Günümüzde dışa aktarılan ses dosyasının kalitesi 192 kHz örnekleme hızında 320 kbps olabilmektedir. Ve bu profesyonel bir ses.

İlk sürüme gelince, yaşam döngüsü tamamen tamamlanmış olarak adlandırılabilir, ancak uygulama yalnızca adını değiştirdiği ve yeni yetenekler edindiği için böyle bir ifade görecelidir.

Kalkınma beklentileri

Yazılım yaşam döngüsünün aşamalarının neler olduğu zaten bellidir. Ancak bu tür teknolojilerin geliştirilmesinden ayrıca bahsetmeye değer.

Söylemeye gerek yok ki, herhangi bir yazılım geliştiricisi piyasada birkaç yıl ayakta kalması muhtemel olmayan geçici bir ürün yaratmakla ilgilenmez. Uzun vadede herkes uzun vadeli kullanımına bakıyor. Bu farklı şekillerde başarılabilir. Ancak, kural olarak, neredeyse hepsi güncellemelerin veya programların yeni sürümlerinin yayınlanmasıyla ilgilidir.

Windows işletim sistemi durumunda bile bu tür eğilimler çıplak gözle görülebilmektedir. Bugün 3.1, 95, 98 veya Millennium modifikasyonları gibi sistemleri kullanan en az bir kullanıcının olması pek olası değildir. Yaşam döngüleri XP'nin piyasaya sürülmesinden sonra sona erdi. Ancak NT teknolojilerini temel alan sunucu sürümleri hâlâ geçerlidir. Bugün Windows 2000 bile yalnızca çok alakalı olmakla kalmıyor, aynı zamanda bazı kurulum veya güvenlik parametrelerinde en son gelişmeleri bile geride bırakıyor. Aynısı NT 4.0 sisteminin yanı sıra Windows Server 2012'nin özel bir modifikasyonu için de geçerlidir.

Ancak bu sistemlerle ilgili olarak gerçekte destek hala beyan ediliyor. yüksek seviye. Ancak bir zamanlar sansasyonel olan Vista açıkça döngüsünün düşüşünü yaşıyor. Sadece tamamlanmamış olduğu ortaya çıkmadı, aynı zamanda o kadar çok hata ve güvenlik sisteminde boşluklar vardı ki, böylesine savunulamaz bir çözümün yazılım pazarına nasıl sunulabileceği ancak tahmin edilebilir.

Ancak herhangi bir türdeki yazılımın (kontrol veya uygulama) geliştirilmesinin yerinde durmadığını söylersek, bugün bunun yalnızca bilgisayar sistemlerini değil aynı zamanda kullanılan teknolojilerin çoğu zaman önde olduğu mobil cihazları da ilgilendirdiğini söyleyebiliriz. bilgisayar sektörü. Sekiz çekirdeğe dayalı işlemci yongalarının ortaya çıkışı en iyisi değil en iyi örnek? Ancak her dizüstü bilgisayar böyle bir donanıma sahip olmakla övünemez.

Bazı ek sorular

Yazılımın yaşam döngüsünü anlamaya gelince, bunun belirli bir zamanda sona erdiğini söylemek oldukça keyfi olur çünkü yazılım ürünleri hala onları yaratan geliştiricilerin desteğine sahiptir. Bunun yerine son, gereksinimleri karşılamayan eski uygulamaları ifade eder. modern sistemler bulundukları ortamda çalışamazlar.

Ancak teknolojik ilerleme göz önüne alındığında bile bunların çoğu yakında savunulamaz hale gelebilir. Daha sonra ya güncellemeleri yayınlamaya ya da başlangıçta yazılım ürününe dahil edilen konseptin tamamını tamamen revize etmeye karar vermeniz gerekecektir. Başlangıç ​​koşullarının, geliştirme ortamının, testlerin ve belirli bir alanda olası uzun vadeli kullanımın değiştirilmesini içeren yeni döngü buradan kaynaklanmaktadır.

Ama içinde bilgisayar teknolojileri Günümüzde üretimde kullanılan otomatik kontrol sistemlerinin (ACS) geliştirilmesi tercih edilmektedir. İşletim sistemleri bile özel programlarla karşılaştırıldığında kaybeder.

Visual Basic tabanlı aynı ortamlar Windows sistemlerinden çok daha popüler olmaya devam ediyor. Ve UNIX sistemleri için uygulama yazılımından hiç bahsetmiyoruz. Amerika Birleşik Devletleri'nin neredeyse tüm iletişim ağları yalnızca onlar için çalışıyorsa ne söyleyebiliriz? Bu arada Linux ve Android gibi sistemler de başlangıçta bu platformda oluşturuldu. Bu nedenle, büyük olasılıkla UNIX'in diğer ürünlerin toplamından çok daha fazla potansiyeli var.

Toplam yerine

Bu durumda yazılım yaşam döngüsünün yalnızca genel ilkelerinin ve aşamalarının verildiğini eklemek gerekir. Aslında başlangıçta belirlenen görevler bile büyük ölçüde farklılık gösterebilir. Buna göre diğer aşamalarda da farklılıklar görülebilmektedir.

Ancak yazılım ürünleri geliştirmeye yönelik temel teknolojiler ve bunların sonraki destekleri açık olmalıdır. Geri kalanı için, oluşturulan yazılımın özellikleri, çalışması beklenen ortamlar, son kullanıcıya veya üretime sağlanan programların yetenekleri ve çok daha fazlası dikkate alınmalıdır.

Ayrıca bazen yaşam döngüleri geliştirme araçlarının uygunluğuna bağlı olabilir. Örneğin, bir programlama dili güncelliğini yitirirse, hiç kimse onu temel alan programlar yazmaz, hatta bunları uygulamaya koymaz. otomatik sistemlerüretim Yönetimi. Burada öne çıkanlar programcılar bile değil, bilgisayar pazarındaki değişikliklere zamanında yanıt vermesi gereken pazarlamacılardır. Ve dünyada bu kadar çok uzman yok. Pazarın nabzını tutabilen yüksek vasıflı personel en çok talep gören personel haline geliyor. Ve bunlar genellikle BT alanındaki belirli bir yazılım ürününün başarısının veya başarısızlığının bağlı olduğu sözde "gri kardinaller"dir.

Programlamanın özünü her zaman anlayamayabilirler, ancak bu alandaki küresel eğilimlere dayanarak yazılım yaşam döngüsü modellerini ve kullanım sürelerini açıkça belirleyebilirler. Etkili yönetim genellikle daha somut sonuçlar üretir. Evet, en azından PR teknolojileri, reklam vb. Kullanıcının bazı uygulamalara ihtiyacı olmayabilir ancak aktif olarak reklamı yapılıyorsa kullanıcı onu yükleyecektir. Bu zaten tabiri caizse bilinçaltı bir seviyedir (bilginin kullanıcının bilincine ondan bağımsız olarak yerleştirildiği 25. karenin aynı etkisi).

Elbette bu tür teknolojiler dünyada yasaklanmıştır ancak çoğumuz bunların hala kullanılabileceğinin ve bilinçaltını belirli bir şekilde etkileyebileceğinin farkında bile değiliz. Haber kanalları ya da internet siteleri tarafından gerçekleştirilen "zombifikasyonun" maliyetine bir bakın; infrasound'a maruz kalma (bu bir opera prodüksiyonunda kullanıldı) gibi daha güçlü araçların kullanımından bahsetmeye bile gerek yok, bunun sonucunda bir kişi bu durumu deneyimleyebilir. korku veya uygunsuz duygular.

Yazılıma dönersek, bazı programların kullanıcının dikkatini çekmek için başlatılırken bir ses sinyali kullandığını eklemekte fayda var. Ve araştırmaların gösterdiği gibi bu tür uygulamalar diğer programlardan daha uygulanabilir. Doğal olarak, başlangıçta kendisine hangi işlev atanırsa atansın, yazılımın yaşam döngüsü de artar. Ve ne yazık ki birçok geliştirici bunu kullanıyor ve bu da bu tür yöntemlerin yasallığı konusunda şüpheler uyandırıyor.

Ancak bunu yargılamak bize düşmez. Yakın gelecekte bu tür tehditleri tespit edecek araçların geliştirilmesi mümkündür. Şu ana kadar bu sadece bir teori, ancak bazı analistlere ve uzmanlara göre pratik uygulamaÇok az şey kaldı. Eğer halihazırda insan beynindeki sinir ağlarının kopyalarını oluşturuyorlarsa ne söyleyebiliriz?

Yazılım yaşam döngüsü standartları

• GOST34.601-90
• ISO/IEC 12207:1995 (Rusça eşdeğeri - GOST R ISO/IEC 12207-99)

Standart GOST 34 .601-90

Yinelemeli model

Sıralı modele bir alternatif, yinelemeli ve artımlı geliştirme modeli olarak adlandırılan modeldir. yinelemeli ve artımlı geliştirme, IID ), 70'lerde T. Gilb'den de alındı. İsim evrimsel model. Bu modele aynı zamanda denir yinelemeli model Ve artımlı model .

IID modeli, proje yaşam döngüsünü, bir bütün olarak projeyle karşılaştırıldığında daha küçük işlevsellik parçalarının oluşturulmasına uygulanan tüm geliştirme süreçlerini içeren, her biri bir "mini projeye" benzeyen bir yineleme dizisine bölmeyi içerir. Her birinin amacı yinelemeler- çalışan bir sürümün alınması yazılım sistemiönceki ve mevcut tüm yinelemelerin entegre içeriği tarafından tanımlanan işlevsellik dahil. Son yinelemenin sonucu, ürünün gerekli tüm işlevlerini içerir. Böylece, her yinelemenin tamamlanmasıyla birlikte ürün bir artış alır - artış- sonuç olarak gelişen yeteneklerine evrimsel olarak. Bu durumda yineleme, artımlılık ve evrim, aynı anlamın farklı kelimelerle, biraz farklı bakış açılarından ifadesidir.

T. Gilb'in belirttiği gibi, “Evrim, istikrarlı bir görünüm yaratmak için tasarlanmış bir tekniktir. Şanslar başarılı yaratım Karmaşık bir sistemin verimliliği, bir dizi küçük adımla uygulandığında ve her adımın açıkça tanımlanmış bir başarı içermesinin yanı sıra başarısızlık durumunda önceki başarılı aşamaya "geri dönme" olanağını da içeriyorsa en üst düzeye çıkarılacaktır. Geliştirici, bir sistemi oluşturmaya yönelik tüm kaynakları eyleme geçirmeden önce gerçek dünyadan geri bildirim sinyalleri alma ve düzeltme fırsatına sahiptir. olası hatalar projede".

IID yaklaşımının da kendine has bir yaklaşımı vardır. olumsuz taraflar, özünde, - arka taraf Avantajlar. İlk olarak, projenin yetenekleri ve sınırlamalarına ilişkin bütünsel bir anlayış çok uzun zamandır eksikti. İkinci olarak, yineleme yaparken daha önce yapılan işlerin bir kısmını atmanız gerekir. Üçüncüsü, uzmanların iş yaparken vicdanlılığı hala azalıyor ki bu psikolojik olarak açıklanabilir, çünkü sürekli olarak "her şey daha sonra yeniden yapılabilir ve geliştirilebilir" hissinin hakimiyetindedirler.

Çeşitli seçenekler Yinelemeli yaklaşım çoğu modern geliştirme metodolojisinde (RUP, MSF,) uygulanmaktadır.

Spiral modeli

Her yineleme, projenin hedeflerinin ve özelliklerinin açıklandığı, elde edilen sonuçların kalitesinin değerlendirildiği ve bir sonraki yinelemenin çalışmasının planlandığı yazılımın bir parçasının veya versiyonunun oluşturulmasına karşılık gelir.

Her yinelemede aşağıdakiler değerlendirilir:

• proje son tarihlerini ve maliyetlerini aşma riski;
• başka bir yineleme gerçekleştirme ihtiyacı;
• sistem gereksinimlerinin anlaşılmasının tamlık ve doğruluk derecesi;
• projeyi sonlandırmanın fizibilitesi.

Spiral modelin evrimsel modele (IID modeli) bir alternatif değil, özel olarak geliştirilmiş bir versiyon olduğunun anlaşılması önemlidir. Ne yazık ki, sarmal model sıklıkla ya yanlışlıkla genel olarak evrimsel modelle eşanlamlı olarak kullanılıyor ya da (daha az hatalı olmamak üzere) IID ile birlikte tamamen bağımsız bir model olarak anılıyor.

Ayırt edici özellik Spiral model, yaşam döngüsünün ve kontrol noktalarının organizasyonunu etkileyen risklere özel önem verilmesidir. Boehm en yaygın (önceliğe göre) 10 riski formüle ediyor:

1. Uzman eksikliği.
2. Gerçekçi olmayan son tarihler ve bütçe.
3. Uygunsuz işlevselliğin uygulanması.
4. Yanlış kullanıcı arayüzü tasarlamak.
5. Mükemmeliyetçilik, gereksiz optimizasyon ve ayrıntılara odaklanma.
6. Sürekli bir değişim akışı.
7. Sistem ortamını tanımlayan veya entegrasyona dahil olan dış bileşenler hakkında bilgi eksikliği.
8. Dış (projeyle ilgili olarak) kaynaklar tarafından gerçekleştirilen çalışmalarda dezavantajlar.
9. Ortaya çıkan sistemin yetersiz performansı.
10. Farklı alanlardaki uzmanların niteliklerindeki boşluk.

Günümüzün spiral modeli aşağıdaki genel kontrol noktalarını tanımlar:

1. Operasyon Kavramı (COO) - sistemin konsepti (kullanımı);
2. Yaşam Döngüsü Hedefleri (LCO) - yaşam döngüsünün hedefleri ve içeriği;
3. Yaşam Döngüsü Mimarisi (LCA) - yaşam döngüsü mimarisi; burada hedef yazılım sisteminin kavramsal mimarisinin hazır olduğundan bahsetmek mümkün;
4. İlk Operasyonel Yetenek (IOC) - oluşturulan ürünün deneme işlemine uygun ilk versiyonu;
5. Nihai Operasyonel Yetenek (FOC) –- tamamlanmış ürün, gerçek operasyon için konuşlandırılmıştır (kurulmuştur ve yapılandırılmıştır).

Yazılım geliştirme metodolojileri

• Microsoft Çözüm Çerçevesi (MSF). 4 aşamayı içerir: analiz, tasarım, geliştirme, stabilizasyon, nesne yönelimli modellemenin kullanımını içerir.
• Ekstrem Programlama Ekstrem Programlama, XP). Metodoloji ekip çalışmasına dayalıdır, etkili iletişim tüm fikri mülkiyet geliştirme projesi boyunca müşteri ile yüklenici arasında. Geliştirme, art arda iyileştirilen prototipler kullanılarak gerçekleştirilir.
• ESPD - karmaşık devlet standartları Rusya Federasyonu Programların ve program dokümantasyonunu geliştirmek, tasarlamak ve dağıtmak için birbiriyle ilişkili kuralların oluşturulması.

Edebiyat

• Bratishchenko V.V. Tasarım bilgi sistemi. - Irkutsk: BGUEP yayınevi, 2004. - 84 s.
• Vendrov A.M. Ekonomik bilgi sistemleri için yazılım tasarımı. - M .: Finans ve İstatistik, 2000.
• Grekul V.I., Denishchenko G.N., Korovkina N.L. Bilgi sistemleri tasarımı. - M.: İnternet Üniversitesi Bilişim Teknolojileri- INTUIT.ru, 2005.
• Mishenin A.I. Ekonomik bilgi sistemleri teorisi. - M .: Finans ve İstatistik, 2000. - 240 s.

Notlar

Wikimedia Vakfı. 2010.

Yazılım yaşam döngüsü

Yazılım yaşam döngüsü, bir yazılım ürünü oluşturma ihtiyacına karar verildiği andan itibaren başlayan ve tamamen hizmetten kaldırıldığı anda sona eren bir süredir. (IEEE Std 610.12)

Yazılım yaşam döngüsünün (LC) aşamalarını belirleme ihtiyacı, geliştiricilerin, problem tanımından yazılım yazma desteğine kadar her aşamada çeşitli kalite kontrol mekanizmalarının kullanılması ve optimum geliştirme yönetimi yoluyla yazılım kalitesini iyileştirme arzusundan kaynaklanmaktadır. Yazılım yaşam döngüsünün en genel temsili, aşağıdakileri içeren temel aşamalar - süreçler biçiminde bir modeldir:

Sistem analizi ve yazılım gereksinimlerinin gerekçelendirilmesi;

Ön (taslak) ve ayrıntılı (teknik) yazılım tasarımı;

Yazılım bileşenlerinin geliştirilmesi, bunların bir bütün olarak entegrasyonu ve yazılımın hata ayıklaması;

Yazılımın test edilmesi, deneme işletimi ve çoğaltılması;

Yazılımın düzenli çalışması, işletimi ve sonuçların analizi için destek;

Yazılımın bakımı, değiştirilmesi ve iyileştirilmesi, yeni versiyonların oluşturulması.

Bu model genel olarak kabul görmektedir ve hem yazılım geliştirme alanındaki yerel düzenlemelere hem de yabancı düzenlemelere uygundur. Teknolojik güvenliğin sağlanması açısından bakıldığında, yabancı modellerde yaşam döngüsü aşamalarını temsil etme özelliklerinin yabancı olduğu için daha ayrıntılı olarak ele alınması tavsiye edilir. yazılım sabotaj tipi yazılım kusurlarının en muhtemel taşıyıcılarıdır.

Yazılım yaşam döngüsü standartları

GOST34.601-90

ISO/IEC 12207:1995 (Rusça eşdeğeri - GOST R ISO/IEC 12207-99)

Yaşam döngüsü modellerinin grafiksel gösterimi, bunların özelliklerinin ve süreçlerin bazı özelliklerinin açıkça vurgulanmasına olanak tanır.

Başlangıçta, önceki çalışmaların sonuçları kullanılarak ana aşamaların birbiri ardına başladığı kademeli bir yaşam döngüsü modeli oluşturuldu. Projenin tüm aşamalarının kesin olarak sabit bir sırayla sıralı olarak uygulanmasını sağlar. Bir sonraki aşamaya geçiş, bir önceki aşamadaki işin tamamen tamamlanması anlamına gelir. Gereksinimlerin oluşturulması aşamasında tanımlanan gereksinimler kesinlikle formda belgelenir. başvuru şartları ve projenin tüm gelişimi boyunca kaydedilir. Her aşama, geliştirmenin başka bir geliştirme ekibi tarafından sürdürülmesine izin vermeye yetecek eksiksiz bir belge setinin yayınlanmasıyla sonuçlanır. Herhangi bir gereksinimin yanlış olması veya yanlış yorumlanması, projenin erken aşamasına "geri dönmenin" gerekli olduğu ve gerekli yeniden çalışmanın yalnızca proje ekibini programın dışına atmakla kalmayıp aynı zamanda çoğu zaman niteliksel bir artışa yol açtığı gerçeğiyle sonuçlanır. maliyetler ve muhtemelen projenin başlangıçta amaçlandığı biçimde sonlandırılmasına kadar. Şelale modeli yazarlarının temel yanılgıları, projenin tüm süreci bir kez geçirdiği, tasarlanan mimarinin iyi ve kullanımı kolay olduğu, uygulama tasarımının makul olduğu ve uygulamadaki hataların test yoluyla kolayca giderilebileceği varsayımlarıdır. Bu model, tüm hataların uygulamada yoğunlaşacağını ve bu nedenle bileşenlerin ve sistemin test edilmesi sırasında bunların ortadan kaldırılmasının eşit şekilde gerçekleştiğini varsayar. Bu nedenle şelale modeli büyük projeler için pek gerçekçi değildir ve yalnızca küçük sistemler oluşturmak için etkin bir şekilde kullanılabilir.

En spesifik olanı sarmal yaşam döngüsü modelidir. Bu model, ilk tasarım aşamalarının yinelemeli sürecine odaklanır. Bu aşamalarda sırasıyla konseptler, gereksinim spesifikasyonları, ön ve detaylı tasarımlar oluşturulur. Her aşamada işin içeriği netleştirilerek oluşturulan yazılımın görünümüne yoğunlaşılır, elde edilen sonuçların kalitesi değerlendirilir ve bir sonraki yinelemenin çalışması planlanır. Her yinelemede aşağıdakiler değerlendirilir:

Proje son tarihlerini ve maliyetlerini aşma riski;

Başka bir yineleme gerçekleştirme ihtiyacı;

Sistem gereksinimlerinin anlaşılmasının tamlık ve doğruluk derecesi;

Projeyi sonlandırmanın fizibilitesi.

Yazılım yaşam döngüsünün standardizasyonu üç yönde gerçekleştirilir. İlk yön, Uluslararası Standardizasyon Örgütü (ISO - Uluslararası Standart Örgütü) ve Uluslararası Elektroteknik Komisyonu (IEC - Uluslararası Elektroteknik Komisyonu) tarafından organize edilir ve teşvik edilir. Bu düzeyde, önemli olan en yaygın teknolojik süreçlerin standardizasyonu Uluslararası işbirliği. İkinci yön, ABD'de Elektrik ve Elektronik Mühendisleri Enstitüsü (IEEE) tarafından Amerikan Ulusal Standartlar Enstitüsü (ANSI) ile birlikte aktif olarak geliştirilmektedir. ISO/IEC ve ANSI/IEEE standartları esas olarak tavsiye niteliğindedir. Üçüncü yön ABD Savunma Bakanlığı (DOD) tarafından teşvik edilmektedir. ABD Savunma Bakanlığı için çalışan şirketler için DOD standartları zorunludur.

Karmaşık bir sistem için, özellikle gerçek zamanlı bir sistem için yazılım tasarlamak için, bilinen tüm işleri dikkate alınan temel süreçler çerçevesinde birleştirmeye dayanan, sistem çapında bir yaşam döngüsü modelinin kullanılması tavsiye edilir. Bu model, çeşitli yazılım projelerinin planlanması, programlanması ve yönetilmesinde kullanılmak üzere tasarlanmıştır.

Bu yaşam döngüsü modelinin aşamalarının, süreçlerin özellikleri, teknik ve ekonomik özellikler ve bunları etkileyen faktörler bakımından önemli ölçüde farklılık gösteren iki parçaya bölünmesi tavsiye edilir.

Yaşam döngüsünün ilk bölümünde, sistem Analizi Yazılımın tasarımı, geliştirilmesi, test edilmesi ve test edilmesi. Bu aşamalardaki işin kapsamı, karmaşıklığı, süresi ve diğer özellikleri önemli ölçüde nesneye ve geliştirme ortamına bağlıdır. Çeşitli yazılım sınıfları için bu tür bağımlılıkların incelenmesi, yeni yazılım sürümleri için çalışma programlarının kompozisyonunu ve temel özelliklerini tahmin etmemizi sağlar.

Yazılımın işletimi ve bakımına yönelik desteği yansıtan yaşam döngüsünün ikinci kısmı, nesnenin ve geliştirme ortamının özellikleriyle nispeten zayıf bir şekilde ilişkilidir. Bu aşamalardaki iş yelpazesi daha istikrarlıdır ancak emek yoğunluğu ve süresi önemli ölçüde değişebilir ve yazılımın yaygın kullanımına bağlı olabilir. Herhangi bir yaşam döngüsü modeli için provizyon Yüksek kalite yazılım sistemleri yalnızca düzenlenmiş kullanıldığında mümkündür teknolojik süreç bu aşamaların her birinde. Bu süreç, mevcut olanlardan seçilmesi veya geliştirme nesnesi ve ona uygun işlerin listesi dikkate alınarak oluşturulması tavsiye edilen geliştirme otomasyon araçlarıyla desteklenir.

Yazılım yaşam döngüsü

Yazılım tasarım metodolojisinin temel kavramlarından biri yazılım yaşam döngüsü (SO) kavramıdır. Yazılımın yaşam döngüsü, yaratılmasının gerekliliğine karar verildiği andan itibaren başlayan ve hizmetten tamamen çekildiği anda sona eren sürekli bir süreçtir.

Ana normatif belge yazılım yaşam döngüsünün düzenlenmesi uluslararası standart ISO/IEC 12207 (ISO - Uluslararası Standardizasyon Örgütü, IEC - Uluslararası Elektroteknik Komisyonu). Yazılım oluşturma sırasında gerçekleştirilmesi gereken süreçleri, etkinlikleri ve görevleri içeren yaşam döngüsü yapısını tanımlar. Bu standartta Yazılım (yazılım ürünü) bir dizi bilgisayar programı, prosedürü ve muhtemelen ilgili dokümantasyon ve veriler olarak tanımlanır. İşlem bazı girdi verilerini çıktı verilerine dönüştüren birbiriyle ilişkili eylemler dizisi olarak tanımlanır. Her süreç, belirli görevler ve bunları çözmek için yöntemler, diğer süreçlerden elde edilen girdi verileri ve sonuçlarla karakterize edilir.

ISO/IEC 12207 standardına göre yazılım yaşam döngüsünün yapısı üç süreç grubuna dayanmaktadır:

· yazılım yaşam döngüsünün ana süreçleri (satın alma, teslimat, geliştirme, işletme, destek);

· Ana süreçlerin (dokümantasyon, konfigürasyon yönetimi, kalite güvencesi, doğrulama, belgelendirme, değerlendirme, denetim, problem çözme) uygulanmasını sağlayan yardımcı süreçler;

· organizasyonel süreçler (proje yönetimi, proje altyapısının oluşturulması, yaşam döngüsünün tanımlanması, değerlendirilmesi ve iyileştirilmesi, eğitim).

Yazılım yaşam döngüsü modelleri

Yaşam döngüsü modeli- Yaşam döngüsü boyunca gerçekleştirilen aşamaların ve aşamaların ilişkisini ve yürütme sırasını belirleyen bir yapı. Yaşam döngüsü modeli, yazılımın özelliklerine ve yazılımın oluşturulduğu ve çalıştığı belirli koşullara bağlıdır. Ana yaşam döngüsü modelleri aşağıdaki gibidir.

1. Kademeli model(XX yüzyılın 70'lerine kadar) bir önceki aşamanın tamamlanmasından sonra bir sonraki aşamaya sıralı geçişi belirler.

Bu model, bilgi entegrasyonu ve uyumluluğu, yazılım, teknik ve organizasyonel arayüz gerektirmeyen, ilgisiz bireysel görevlerin otomasyonu ile karakterize edilir.

İtibar: bireysel sorunları çözerken geliştirme süresi ve güvenilirlik açısından iyi göstergeler.

Kusur: Uzun tasarım süresi boyunca sistem gereksinimlerindeki değişkenlik nedeniyle büyük ve karmaşık projelere uygulanamaz.

2. Yinelemeli model(XX yüzyılın 70-80'leri) “aşağıdan yukarıya” tasarım teknolojisine karşılık gelir. Bir sonraki aşamayı tamamladıktan sonra önceki aşamalara yinelemeli dönüşlere izin verir;

Model, bireysel problemler için elde edilen tasarım çözümlerinin sistem çapındaki çözümlere genelleştirilmesini sağlar. Bu durumda daha önce formüle edilen gereksinimlerin revize edilmesi ihtiyacı ortaya çıkmaktadır.

İtibar: projede hızlı bir şekilde ayarlamalar yapma yeteneği.

Kusur:çok sayıda yinelemeyle tasarım süresi artar, tasarım çözümleri ve dokümantasyonda farklılıklar ortaya çıkar, işlevsel ve sistem mimarisi yazılım oluşturdu. Eskisini yeniden tasarlama veya yaratma ihtiyacı yeni sistem uygulama veya işletme aşamasından hemen sonra gerçekleşebilir.

3. Sarmal model(XX yüzyılın 80-90'ları) “yukarıdan aşağıya” tasarım teknolojisine karşılık gelir. Yazılım uzantısına izin veren bir yazılım prototipinin kullanımını içerir. Sistem tasarımı, gereksinimlerin detaylandırılmasından program kodunun detaylandırılmasına kadar olan yolu döngüsel olarak tekrarlar.

Bir sistem mimarisi tasarlarken, öncelikle işlevsel alt sistemlerin bileşimi belirlenir ve sistem genelindeki sorunlar çözülür (entegre bir veritabanının organizasyonu, bilgi toplama, iletme ve depolama teknolojisi). Daha sonra bireysel problemler formüle edilir ve bunları çözmek için teknoloji geliştirilir.

Programlama sırasında önce ana yazılım modülleri, ardından bireysel işlevleri yerine getiren modüller geliştirilir. Öncelikle modüllerin birbirleriyle ve veri tabanı ile etkileşimi sağlanır, ardından algoritmaların uygulanması sağlanır.

Avantajları:

1. Yineleme sayısını ve dolayısıyla düzeltilmesi gereken hata ve tutarsızlıkların sayısını azaltmak;

2. tasarım süresinin kısaltılması;

3. proje belgelerinin oluşturulmasının basitleştirilmesi.

Kusur: sistem çapındaki havuzun kalitesi için yüksek gereksinimler ( ortak taban tasarım verileri).

Spiral model temeldir hızlı uygulama geliştirme teknolojileri veya gelecekteki sistemin son kullanıcılarının yaratılma sürecine aktif katılımını içeren RAD teknolojisi (hızlı uygulama geliştirme). Bilgi mühendisliğinin ana aşamaları şunlardır:

· Bilgi stratejisinin analizi ve planlanması. Kullanıcılar, uzman geliştiricilerle birlikte sorunlu alanın belirlenmesine katılırlar.

· Tasarım. Kullanıcılar, geliştiricilerin rehberliğinde teknik tasarıma katılırlar.

· Yapı. Geliştiriciler, yazılımın çalışan bir versiyonunu 4. nesil dilleri kullanarak tasarlar;

· Uygulama. Geliştiriciler, kullanıcıları yeni yazılım ortamında çalışacak şekilde eğitir.