Yazılım geliştirme yaklaşımları. Yazılım geliştirmeye yapısal bir yaklaşım. Çevik gelişimin ilkeleri ve anlamı
1.Kodlama
Yazılım geliştirme aşamasında aşağıdaki ana eylemler gerçekleştirilir: kodlama; test yapmak; bir PP yardım sisteminin geliştirilmesi; kullanıcı belgelerinin oluşturulması; Yazılımın versiyonunun oluşturulması ve kurulumu,
Kodlama, yüksek seviyeli ve düşük seviyeli tasarım sonuçlarını bitmiş bir yazılım ürününe dönüştürme sürecidir. Başka bir deyişle, kodlama sırasında derlenen yazılım modeli, mevcut dillerden herhangi biri olabilen seçilen programlama dili kullanılarak açıklanır. Dil seçimi müşterinin talebi üzerine veya çözülmekte olan sorun dikkate alınarak gerçekleştirilir ve kişisel deneyim geliştiriciler.
Kodlama yaparken, seçilen dil için standardı takip etmelisiniz; örneğin, C dili için ANSI C ve C++ için ISO/IEC 14882 “C++ Programlama Dili Standardı”dır.
Bir programlama dili için genel kabul görmüş standarda ek olarak, bir şirket program yazma kuralları için kendi ek gerekliliklerini de geliştirebilir. Bunlar esas olarak program metninin biçimlendirilmesine ilişkin kurallarla ilgilidir.
Standart ve şirket kurallarına uymak, doğru çalışan, okunması kolay ve diğer geliştiriciler tarafından anlaşılabilir, geliştirici, oluşturulma tarihi, adı ve amacı hakkında bilgilerin yanı sıra yapılandırma yönetimi için gerekli verileri içeren bir program oluşturmanıza olanak tanır.
Kodlama aşamasında programcı programları kendisi yazar ve test eder. Bu tür testlere birim testi denir. Yazılım testiyle ilgili tüm konular Bölüm'de tartışılmaktadır. Şekil 10'da yazılım geliştirme aşamasında kullanılan test teknolojisi de burada anlatılmaktadır. Bu teknolojiye test denir "cam kutu" (cam kutu); bazen buna test de denir "beyaz kutu" (beyaz kutu) klasik “kara kutu” kavramının aksine.
Kara kutu testinde bir program, iç yapısı bilinmeyen bir nesne gibi ele alınır. Testi yapan kişi verileri girer ve sonucu analiz eder ancak programın nasıl çalıştığını tam olarak bilmez. Uzman, testleri seçerken, kendi bakış açısına göre ilginç olan ve standart dışı sonuçlara yol açabilecek girdi verilerini ve koşullarını arar. Kendisi öncelikli olarak, test edilen programda hataların ortaya çıkma ihtimalinin yüksek olduğu her girdi verisi sınıfının temsilcileriyle ilgilenmektedir.
Bir “cam kutuyu” test ederken durum tamamen farklıdır. Testi yapan kişi (bu durumda programcının kendisi), erişebildiği kaynak kodu bilgisine dayalı olarak testler geliştirir. tam erişim. Sonuç olarak aşağıdaki avantajları elde eder.
1. Testin yönü. Programcı programı parçalar halinde test edebilir, test edilen modülü çağıran ve programcının ilgisini çeken verileri bu modüle ileten özel test alt programları geliştirebilir. Ayrı bir modülü “cam kutu” olarak test etmek çok daha kolaydır.
2.Tam kod kapsamı. Programcı her testte hangi kod parçalarının işe yarayacağını her zaman belirleyebilir. Kodun diğer hangi dallarının test edilmeden kaldığını görür ve bunların hangi koşullar altında test edileceğini seçebilir. Aşağıda, gerçekleştirilen testlerin kod kapsamı derecesinin nasıl takip edileceğini açıklıyoruz.
3. Komutların akışını kontrol edebilme yeteneği. Programcı her zaman programda bir sonraki adımda hangi fonksiyonun çalıştırılması gerektiğini ve mevcut durumunun ne olması gerektiğini bilir. Bir programın düşündüğü gibi çalışıp çalışmadığını öğrenmek için programcı, programın yürütülmesiyle ilgili bilgileri görüntüleyen hata ayıklama komutlarını ekleyebilir veya bunu yapmak için özel bir program kullanabilir. yazılım hata ayıklayıcı denir. Hata ayıklayıcı birçok yararlı şey yapabilir: program komutlarının yürütme sırasını izler ve değiştirir, değişkenlerinin içeriğini ve bellekteki adreslerini gösterir, vb.
4.Veri bütünlüğünü izleme yeteneği. Programcı her veri öğesini programın hangi bölümünün değiştirmesi gerektiğini bilir. Verilerin durumunu izleyerek (aynı hata ayıklayıcıyı kullanarak), verilerin yanlış modüller tarafından değiştirilmesi, yanlış yorumlanması veya başarısız organizasyon gibi hataları tespit edebilir.Programcı testi kendisi otomatikleştirebilir.
5.İç sınır noktalarının görünümü. İÇİNDE kaynak kodu programın dışarıdan gizlenen sınır noktaları görülebilir. Örneğin, belirli bir eylemi gerçekleştirmek için tamamen farklı birkaç algoritma kullanılabilir ve koda bakmadan programcının hangisini seçtiğini belirlemek imkansızdır. Diğer bir yaygın örnek, giriş verilerini geçici olarak depolamak için kullanılan arabellekteki taşma sorunu olabilir. Programcı arabelleğin ne kadar veri taşıyacağını anında anlayabilir ve binlerce test yapmasına gerek kalmaz.
6. Seçilen algoritmaya göre belirlenen test olasılığı. Çok karmaşık hesaplama algoritmaları kullanan veri işlemenin test edilmesi özel teknolojiler gerektirebilir. Klasik örnekler arasında matris dönüşümü ve veri sıralama yer alır. Bir programcıdan farklı olarak bir test uzmanının, hangi algoritmaların kullanıldığını tam olarak bilmesi gerekir, bu nedenle özel literatüre başvurması gerekir.
Cam kutu testi programlama sürecinin bir parçasıdır. Programcılar bu işi sürekli yaparlar, her modülü yazdıktan sonra test ederler ve sisteme entegre ettikten sonra tekrar test ederler.
Birim testi gerçekleştirirken yapısal veya fonksiyonel test teknolojisini veya her ikisini birden kullanabilirsiniz.
Yapısal test bir tür cam kutu testidir. Ana fikri, test edilecek yazılım yolunun doğru seçimidir. Onun aksine fonksiyonel testler kara kutu testleri kategorisine girer. Her program fonksiyonu, giriş verileri girilerek ve çıkışı analiz edilerek test edilir. Aynı zamanda programın iç yapısı da çok nadiren dikkate alınmaktadır.
Yapısal testler çok daha güçlü olmasına rağmen teorik temelçoğu test uzmanı fonksiyonel testi tercih eder. Yapısal testler matematiksel modellemeye daha uygundur ancak bu onun daha etkili olduğu anlamına gelmez. Her teknoloji, diğerini kullanırken gözden kaçırılan hataları tanımlamanıza olanak tanır. Bu açıdan eşit derecede etkili denilebilir.
Testin amacı yalnızca tam yol program (başlangıçtan bitişe kadar yürüttüğü komutların sırası), aynı zamanda bireysel bölümleri. Bir programı çalıştırmanın tüm olası yollarını test etmek kesinlikle gerçekçi değildir. Bu nedenle test uzmanları, kesinlikle test edilmesi gereken grupları olası tüm yollardan belirler. Seçim için adı verilen özel kriterleri kullanırlar. kapsam kriterleri (kapsam kriterleri), bu da çok gerçek (oldukça büyük olsa bile) sayıda test belirler. Bu kriterlere bazen denir mantıksal kapsam kriterleri, veya tamlık kriterleri.
3. Bir yardım sisteminin geliştirilmesi yazılım ürünü. Kullanıcı Dokümantasyonu Oluşturma
Proje çalışanlarından birinin dokümantasyonun teknik editörü olarak atanması tavsiye edilir. Bu çalışan aynı zamanda başka işler de yapabilir, ancak diğer çalışanlar da geliştiriyor olsa bile asıl görevi dokümantasyonun analizi olmalıdır.
Çoğu zaman bir yazılımın oluşturulması üzerinde birkaç kişinin çalıştığı görülür, ancak hiçbiri yazılımın kalitesi konusunda tam sorumluluk taşımaz. Sonuç olarak, yazılım daha fazla kişi tarafından geliştirilmesinden faydalanmakla kalmıyor, aynı zamanda kaybediyor çünkü her biri bilinçaltında sorumluluğu diğerine kaydırıyor ve meslektaşlarının işin şu veya bu kısmını yapmasını bekliyor. Bu sorun, teknik dokümantasyonun kalitesi ve doğruluğu konusunda tüm sorumluluğu üstlenen bir editörün atanmasıyla çözülür.
PP yardım sistemi, kullanım kılavuzu için geliştirilen materyal temel alınarak oluşturulmuştur. Bu işi yapmaktan sorumlu kişi tarafından oluşturulur ve oluşturulur. Bu, bir teknik editör olabileceği gibi, teknik editörle birlikte geliştiricilerden biri de olabilir.
İyi belgelenmiş bir PP aşağıdaki avantajlara sahiptir.
1. Kullanım kolaylığı. Yazılım iyi belgelenmişse uygulanması çok daha kolaydır. Kullanıcılar bunu daha hızlı öğrenir, daha az hata yapar ve bunun sonucunda işlerini daha hızlı ve daha verimli yaparlar.
2. Daha düşük maliyet teknik Destek. Kullanıcı ihtiyaç duyduğu eylemleri nasıl gerçekleştireceğini çözemediğinde PCB üreticisinin teknik destek servisini arar. Böyle bir hizmeti çalıştırmak çok pahalıdır. İyi bir kılavuz, kullanıcıların sorunları kendi başlarına çözmelerine ve teknik destek ekibiyle iletişime geçme ihtiyacını azaltmalarına yardımcı olur.
3. Yüksek güvenilirlik. Anlaşılmaz veya özensiz dokümantasyon, yazılımı daha az güvenilir hale getirir, çünkü kullanıcılarının hata yapma olasılığı daha yüksektir ve bunlara neyin sebep olduğunu ve sonuçlarıyla nasıl başa çıkacaklarını anlamakta zorluk çekerler.
Bakım kolaylığı. Kullanıcı hatalarından kaynaklanan sorunların analizi için büyük miktarda para ve zaman harcanmaktadır. Yeni yazılım sürümlerinde yapılan değişiklikler genellikle eski işlevlerin arayüzünde yapılan basit değişikliklerdir. Kullanıcıların sonunda yazılımı nasıl kullanacaklarını anlamaları ve teknik desteği aramayı bırakmaları için tanıtılırlar. Büyük ölçüde iyi yönetim
Bilgisayar bilimi, sibernetik ve programlama
Yineleme N Birleşik Geliştirme Süreci yazılım USDP Kullanım Senaryosu Modeli, uygulamanın kullanılacağı durumları açıklar. Analitik model, uygulamaya yönelik temel sınıfları tanımlar. Tasarım modeli, sınıflar ve tahsis edilmiş nesneler arasındaki bağlantıları ve ilişkileri tanımlarken, dağıtım modeli, yazılımın bilgisayarlar arasındaki dağıtımını açıklar.
Ders No.20
Yazılım geliştirmede genel prensipler ve yaklaşımlar
Yazılım geliştirme modelleri
- Vodopadnaya
- Kademeli model
- Sarmal
- Ekstrem Programlama
- Artımlı
- MSF metodolojisi
Şelale Modeli
Spiral modeli
Artımlı geliştirme
Gereksinimlerin analizi
Tasarım
Uygulama
Bileşen
test yapmak
Entegrasyon
Test yapmak
bir bütün
Yineleme 1 Yineleme 2…. Yineleme N
Birleşik Yazılım Geliştirme Süreci (USDP)
- Kullanım senaryosu modeli, uygulamanın kullanılacağı durumları açıklar.
- Analitik model, uygulamaya yönelik temel sınıfları tanımlar.
- Tasarım modeli, sınıflar ve seçilen nesneler arasındaki bağlantıları ve ilişkileri açıklar.
- Dağıtım modeli, yazılımın bilgisayarlar arasındaki dağıtımını açıklar.
- Uygulama modeli, program kodunun iç organizasyonunu açıklar.
- Bir test modeli test bileşenlerinden, test prosedürlerinden ve çeşitli test senaryolarından oluşur.
MSF metodolojisi
Tipik yazılım ürünü mimarisi bileşenleri ve tipik yazılım gereksinimleri
hata toleransıhataları tespit ederek, sistem için kötü sonuçları geri yükleyerek ve yerelleştirerek güvenilirliğini artıran bir dizi sistem özelliği. Hata toleransını sağlamak için herhangi bir gerçek sistemi tasarlarken, sistem arızasına yol açabilecek tüm olası durumları sağlamak ve arızalarla başa çıkmak için mekanizmalar geliştirmek gerekir.
Güvenilirlik sistemin çeşitli arızalara ve arızalara dayanma yeteneği.
Reddetme bu bir sistem geçişihatanın bir sonucu olarak tamamen çalışamaz bir duruma dönüşür.
Kaza sistemin işleyişinde sistem arızasına yol açmayan bir hata.
Belirli bir süre boyunca ne kadar az arıza ve arıza olursa sistem o kadar güvenilir kabul edilir.
İlginizi çekebilecek diğer çalışmaların yanı sıra |
|||
| 57355. | Organik bileşiklerin çeşitleri, sınıflandırılması. Canlı doğanın organik maddeleri | 48,5 KB | |
| Organik bileşiklerin çeşitliliği, karbon atomlarının birbirlerine basit ve çoklu bağlarla bağlanarak neredeyse sınırsız sayıda atomun zincirlere bağlı olduğu bileşikler oluşturma konusundaki eşsiz yeteneği ile belirlenir: döngüler, bisikletler, üç tekerlekli bisikletler, çoklu döngüler, çerçeveler vb. | |||
| 57359. | Sözlü bilgi modellerinin işlenmesi | 291 KB | |
| Temel kavramlar: model; bilgi modeli; sözel bilgi modeli; dipnot; soyut. Özet Lat'ten özet. 2 için bir not oluşturun. Belgeyi Not adı altında kendi klasörüne kaydedin. | |||
| 57361. | Sayı ve şekil 3. Sayıları sınırlara göre hizalama 3. Sayıları yazma 3. Nesnelerin sayısını hizalama | 35,5 KB | |
| Kaç canlı vardır Kim birinci sırada Kim son sırada 1. sırada kim 2. sırada Kimler var Kirpinin komşularını isimlendirin. Sağ elini kullanan sincap kimdir Solak zürafa kimdir En büyük kimdir En küçük kim Yaratıkların ortasında duran Gra Göster bana, merhamet etme. | |||
Bugün yazılım mühendisliğinde EIS yazılımının geliştirilmesine yönelik iki ana yaklaşım vardır; bunlar arasındaki temel fark, Farklı yollar sistemlerin ayrışması. İlk yaklaşıma fonksiyonel-modüler veya yapısal denir. Sistemin yapısının, işlevlerin hiyerarşisi ve bireyler arasındaki bilgi aktarımı açısından tanımlandığı işlevsel ayrıştırma ilkesine dayanır. fonksiyonel elemanlar. İkinci, nesne yönelimli yaklaşım nesne ayrıştırmayı kullanır. Bu durumda sistemin yapısı nesneler ve bunlar arasındaki bağlantılar açısından, sistemin davranışı ise nesneler arasındaki mesaj alışverişi açısından tanımlanır.
Dolayısıyla, EIS yazılım geliştirmeye yönelik yapısal yaklaşımın özü, otomatik işlevlere ayrıştırılmasında (dağıtılmasında) yatmaktadır: sistem işlevsel alt sistemlere bölünmüştür, bunlar da alt işlevlere, bunlar görevlere vb. özel prosedürler. Aynı zamanda otomatik sistem, tüm bileşenlerin birbirine bağlı olduğu bütünsel bir görünümü korur. Bireysel görevlerden tüm sisteme kadar "aşağıdan yukarıya" bir sistem geliştirirken bütünlük kaybolur, tanımlarken sorunlar ortaya çıkar bilgi etkileşimi bireysel bileşenler.
Yapısal yaklaşımın en yaygın yöntemlerinin tümü bir takım genel ilkelere dayanmaktadır. Temel ilkeler şunlardır:
“böl ve yönet” ilkesi (bkz. alt bölüm 2.1.1);
Hiyerarşik sıralama ilkesi, bir sistemin bileşenlerini, her düzeyde yeni ayrıntıların eklenmesiyle hiyerarşik ağaç yapıları halinde düzenleme ilkesidir.
İki temel ilkenin vurgulanması, geri kalan ilkelerin ikincil olduğu anlamına gelmez; çünkü bunlardan herhangi birinin göz ardı edilmesi, öngörülemeyen sonuçlara (tüm projenin başarısızlığı dahil) yol açabilir. Bu ilkelerin başlıcaları şunlardır:
soyutlama ilkesi - sistemin temel yönlerini vurgulamak ve önemsiz olanlardan soyutlamak;
tutarlılık ilkesi - sistem öğelerinin geçerliliği ve tutarlılığı;
Veri yapılandırma ilkesi: Veriler yapılandırılmalı ve hiyerarşik olarak organize edilmelidir.
Yapısal yaklaşım temel olarak sistemin işlevsel yapısını ve veriler arasındaki ilişkileri tanımlayan iki araç grubunu kullanır. Her araç grubu belirli model türlerine (diyagramlara) karşılık gelir; bunlardan en yaygın olanları şunlardır:
DFD (Veri Akış Şemaları) - veri akış şemaları;
SADT (Yapılandırılmış Analiz ve Tasarım Tekniği - yapısal analiz ve tasarım yöntemi) - modeller ve ilgili fonksiyonel diyagramlar;
ERD (Varlık-İlişki Diyagramları) - varlık-ilişki diyagramları.
Veri akış diyagramları ve varlık-ilişki diyagramları CASE araçlarında en sık kullanılan model türleridir.
Özel görünüm Listelenen diyagramların özellikleri ve tasarımlarının yorumlanması, yazılım yaşam döngüsünün aşamasına bağlıdır.
Yazılım gereksinimlerinin oluşturulması aşamasında SADT modelleri ve DFD kullanılarak "OLDUĞU GİBİ" modeli ve "TO-BE" modeli oluşturularak kuruluşun iş süreçlerinin mevcut ve önerilen yapısı ve aralarındaki etkileşim yansıtılır ( SADT modellerinin kullanımı kural olarak yalnızca bu aşamayla sınırlıdır, çünkü bunlar başlangıçta yazılım tasarımına yönelik değildir). ERD'nin yardımıyla organizasyonda kullanılan verilerin tanımı, veritabanı uygulama araçlarından (DBMS) bağımsız olarak kavramsal düzeyde gerçekleştirilir.
Tasarım aşamasında, DFD'ler tasarlanan yazılım sisteminin yapısını tanımlamak için kullanılır ve geliştirilebilir, genişletilebilir ve yeni tasarımlarla desteklenebilir. Benzer şekilde, ERD'ler iyileştirilir ve verilerin sonraki bir veritabanı şeması oluşturulmasına uygun mantıksal düzeyde temsilini tanımlayan yeni yapılar ile desteklenir. Bu modeller yazılım sistemi mimarisini, program blok diyagramlarını, hiyerarşiyi yansıtan diyagramlarla desteklenebilir. ekran formları ve menü vb.
Listelenen modeller, sistemin mevcut veya yeni geliştirilmiş olmasına bakılmaksızın, EIS yazılımının tam bir tanımını sağlar. Her özel durumda diyagramların bileşimi, sistemin karmaşıklığına ve açıklamasının gerekli eksiksizliğine bağlıdır.
Bu bölümde verilen diyagram örneklerinin çoğunun konu alanı, en eksiksiz açıklaması Rusya Federasyonu Vergi Kanunu'nda yer alan Rusya Federasyonu vergi sistemidir. Bilgi Teknolojisi Rusya Federasyonu vergi sisteminde kullanılan belirli özelliklere sahiptir.
Dolayısıyla, EIS yazılım geliştirmeye yönelik yapısal yaklaşımın özü, otomatik işlevlere ayrıştırılmasında (dağıtılmasında) yatmaktadır: sistem işlevsel alt sistemlere bölünmüştür, bunlar da alt işlevlere, bunlar görevlere vb. özel prosedürler. Sistem aynı zamanda tüm bileşenlerin birbirine bağlı olduğu bütünsel bir görünümü de korur. Bireysel görevlerden tüm sisteme kadar "aşağıdan yukarıya" bir sistem geliştirirken bütünlük kaybolur ve bireysel bileşenlerin bilgi etkileşimini açıklarken sorunlar ortaya çıkar.
Yapısal yaklaşımın en yaygın yöntemlerinin tümü bir dizi genel prensibe dayanmaktadır:
1. “Böl ve yönet” ilkesi;
2. Hiyerarşik sıralama ilkesi, bir sistemin bileşenlerini, her düzeyde yeni ayrıntıların eklenmesiyle hiyerarşik ağaç yapıları halinde düzenleme ilkesidir.
İki temel ilkeyi birbirinden ayırmak, geri kalan ilkelerin ikincil olduğu anlamına gelmez, çünkü bunlardan herhangi birinin göz ardı edilmesi öngörülemeyen sonuçlara yol açabilir (tüm projenin başarısızlığı dahil). Bu ilkelerin başlıcaları şunlardır:
1. Soyutlama ilkesi - sistemin temel yönlerini vurgulamak ve önemsiz olanlardan soyutlamak.
2. Sistem elemanlarının tutarlılığı, geçerliliği ve tutarlılığı ilkesi.
3. Yapılanma ilkesi veri - veri yapılandırılmalı ve hiyerarşik olarak organize edilmelidir.
Yapısal yaklaşımda temel olarak sistemin işlevsel yapısını ve veriler arasındaki ilişkileri tanımlayan iki grup araç bulunmaktadır. Her araç grubu belirli model türlerine (diyagramlara) karşılık gelir; bunlar arasında en yaygın olanları şunlardır:
· DFD (Veri Akış Şemaları) - veri akış şemaları;
· SADT (Yapılandırılmış Analiz ve Tasarım Tekniği - yapısal analiz ve tasarım metodolojisi) - modeller ve ilgili fonksiyonel diyagramlar: IDEF0 (sistemlerin fonksiyonel modellemesi), IDEF1х (veritabanlarının kavramsal modellemesi), IDEF3х (kalitesini değerlendirmek için sistemlerin inşası) notasyonları bir nesnenin işi; grafik açıklaması süreçlerin akışı, süreçlerin etkileşimi ve bu süreçler tarafından değiştirilen nesneler);
· ERD (Varlık - İlişki Diyagramları) - varlık-ilişki diyagramları.
Yazılım gereksinimlerinin oluşturulması aşamasında yapısal yaklaşımın (yapısal analiz) neredeyse tüm yöntemleri iki grup modelleme aracı kullanır:
1. Sistemin gerçekleştirmesi gereken işlevleri ve bu işlevler - DFD veya SADT (IDEF0) arasındaki ilişkileri gösteren diyagramlar.
2. Verileri ve ilişkilerini (ERD) modelleyen diyagramlar.
Listelenen diyagramların spesifik biçimi ve tasarımlarının yorumlanması, yazılım yaşam döngüsünün aşamasına bağlıdır.
Yazılım gereksinimlerinin oluşturulması aşamasında SADT modelleri ve DFD kullanılarak “OLDUĞU GİBİ” modeli ve “TO-BE” modeli oluşturularak kuruluşun iş süreçlerinin mevcut ve önerilen yapısı ve aralarındaki etkileşim yansıtılmaktadır ( SADT modellerinin kullanımı, başlangıçta yazılım tasarımına yönelik olmadığından genellikle yalnızca bu aşamayla sınırlıdır. ERD'nin yardımıyla, kuruluşta kullanılan verilerin tanımı, veritabanı uygulama araçlarından (DBMS) bağımsız olarak kavramsal düzeyde gerçekleştirilir.
1. Programlama teknolojisinin amacı. Programlama teknolojisinin gelişiminin tarihi. Yazılım projesi türleri. Programlama teknolojisinin bileşenleri. Proje, ürün, süreç ve insanlar
2. Program yaşam döngüsü. Gelişimin döngüsel doğası. Programlama teknolojisinin temel kavramları. Süreçler ve modeller. Aşamalar ve dönüşler. Kilometre taşları ve eserler. Paydaşlar ve çalışanlar.
3. Gereksinimlerin belirlenmesi ve analizi. Yazılım gereksinimleri. Gereksinim geliştirme akış şeması. İhtiyaç Yönetimi.
4. Mimari ve detaylı tasarım. Uygulama ve kodlama. Test etme ve doğrulama. Kalite kontrol süreci. Beyaz kutu ve kara kutu yöntemleri. Denetimler ve incelemeler. Hedefleri test etmek. Doğrulama, doğrulama ve sistem testi. Bakım ve sürekli geliştirme.
5. Geliştirme sürecinin modelleri. Şelale ve konveyör modelleri. Spiral ve artımlı modeller. Esnek geliştirme süreci modelleri.
6. Bir süreç modelinin oluşturulması. Süreç gereksinimlerini tanımlayın. Kullanılan aşamalar, kilometre taşları ve eserler. Bir süreç mimarisinin seçilmesi. Standart bir projeyi yürütme prosedürü. Belgelenmiş prosedürler.
7. Geliştirme ekibi modelleri. Gelişimin kolektif doğası. Optimum takım büyüklüğü. Proje katılımcılarının itaati. Ekip gelişimi ve personel gelişimi. Uzmanlaşma, işbirliği ve etkileşim.
8. Geliştirme ekibi modelleri. Hiyerarşik takım modeli. Cerrahi ekip yöntemi. Akran takım modeli.
9. Programlamanın doğası. Programlama bilimi. Programlama sanatı. Programlama sanatı. Programlama paradigmaları. Yapılandırılmış programlama. Mantık programlama. Nesne yönelimli programlama.
10. Yazılım mimarisi. Olay yönetimi. İstemci/sunucu mimarisi. Hizmetler. Üç katmanlı mimari. Program tasarımı. Kavramsal tasarım. Mantıksal tasarım. Detaylı tasarım.
1. Novikov yazılım geliştirmeye yaklaşıyor" http://window. /window_catalog/files/r60368/itmo307.pdf.
2. Ekstrem programlama. – St.Petersburg: Peter, 2002.
3. Yazılım geliştirme teknolojisi. – St.Petersburg. : Peter, 2004.
4. Brooks Jr. tasarlanmış ve yaratılmıştır yazılım sistemleri. M.: Nauka, 1975; çevirinin yeni baskısı: Efsanevi Adam-Ay. SPb.: SEMBOL+, 1999.
5. Algoritmalar + veri yapıları = programlar. M., Mir, 1978.
6. Sistematik programlama. Giriiş. M.: Mir, 1977.
7. Yapılandırılmış programlama. M.: Mir, 1975.
8. Programlama disiplini. M.: Mir, 1978.
9. Yazılım geliştirme teknolojileri. – St.Petersburg: Peter, 2002.
10. Terekhov programlaması. M.: BİNOM, 2006.
11. Rambo J. Birleşik yazılım geliştirme süreci. St.Petersburg: Peter, 2002.
Yöneticiler için ekonomi teorisi
Temel mikroekonomik teoriler. Ekonomik süreçlerin analizinde uygulama örnekleri. Temel makroekonomik teoriler. Ekonomik süreçlerin analizinde uygulama örnekleri. Ekonomik süreçleri yönetmenin ilke ve yöntemleri. Ekonomik süreçlerin gelişim düzeyini değerlendirme araçları Genişletilmiş yeniden üretim sorunları. Rusya ekonomisinin ekonomik büyüme faktörleri. Sürdürülebilir kalkınmanın kriterleri ve göstergeleri. Döngüsel dalgalanmaların yumuşatılması. Ekonomik kalkınmanın hızını değerlendirmede çarpan ve hızlandırıcının rolü. Ekonomide üretim fonksiyonları. Ekonomik süreçlerin analizinde uygulama örnekleri. Kâr. Kârı etkileyen göstergelerin hesaplanması, grafik görüntü başabaş noktası. Yatırım politikasını uygulama metodolojisi.İktisat teorisi dersi: üniversiteler için ders kitabı / Ed. . –Kirov: “ASA”, 2004. Kolemaev - matematiksel modelleme. Makroekonomik süreç ve sistemlerin modellenmesi: ders kitabı. M.: UNITY-DANA, 2005. Bazhin sibernetiği. Kharkov: Consul, 2004. Matematiksel modelleme yöntemleri üzerine Leushin çalıştayı: ders kitabı. Nijniy Novgorod Eyaleti teknoloji. univ. - N. Novorod, 2007. Ekonomiyle ilgili politikacılar: Ekonomi alanında Nobel ödüllülerin dersleri. M.: Modern ekonomi ve hukuk, 2005. Cheremnykh. İleri düzey: Ders Kitabı.-M.:INFRA-M, 2008. Mini ekonomi kurumlarının evrimi. İktisat Enstitüsü, Rusya Bilimler Akademisi Ural Şubesi, - M.: Nauka, 2007.
Geliştirme ve yönetimle ilgili karar verme teknolojileri [N]
Bir yöneticinin faaliyetinin temeli olarak karar verme. Karar teorisine giriş. Karar teorisinin temel kavramları. İşletme yönetimi modelleri ve bunların karar almaya etkisi. Çeşitli yollarÇözümlerin sınıflandırılması. Sınıflandırmalar: formalite derecesine göre, rutin derecesine göre, sıklığa göre, aciliyete göre, hedeflere ulaşma derecesine göre, alternatif seçme yöntemine göre. Temel karar verme yöntemleri. İsteğe bağlı karar verme yöntemleri. Karar vermenin hedefleri. Çözüm arama zamanı. Temel hatalar Matematiksel karar verme yöntemleri. Karar teorisinin matematiksel yönleri. Operasyon araştırması. Karar vermede matematiksel yaklaşım. Karar ağacı. Kalkınma ve karar verme modelleri. Oyun Teorisi. Karar vermenin matematiksel yöntemleri. Karar teorisinin matematiksel yönleri. Kuyruk teorisinin modelleri. Envanter yönetimi modelleri. Doğrusal programlama modeli. Taşıma görevleri. Simülasyon modelleme. Ağ analizi. Ekonomik analiz. Rasyonel modellerin sınırlamaları. Bir grupta gelişim ve karar vermenin özellikleri. Kümelerin bağlantı derecesine dayalı olarak grup uyumunu belirlemeye yönelik bir yöntem. Kolektif karar verme yöntemleri. Konsensüs yöntemi. Oy verme yöntemleri. Yaratıcı karar verme yöntemleri. Beyin fırtınası. Fikir konferansı. Gemi Konseyi. De Bono'nun "Düşünme Şapkaları" yöntemi. Yaratıcı problem çözme teorisi (TRIZ). Mükemmel son çözüm. TRIZ kullanarak problem örnekleri ve çözümleri. Benzersiz ve yaratıcı kararlar alırken TRIZ yöntemlerinin uygulanması. Çözüm fikirleri geliştirme ve bunları duruma uyarlama yöntemleri. Hedef ağacı modeli. Çıkarları koordine etme stratejisi. Çıkarları koordine etmek için kararların oluşturulması. Karşı tarafların çıkarlarını belirleme yöntemleri. Karar destek sistemleri (uzman sistemler). Karar verme sistemlerinin yaratılışının tarihi. Karar verme sistemlerinin sınıflandırılması. Tipik yapı uzman sistem. Bilgiyi sunma yöntemleri. Mantıksal çıkarım yöntemleri. Uzman sistemlerin pratikte uygulanması.I. Karar Verme Teorisi: Ders Kitabı. - M.: Sınav, 2006. - 573 s. I. Karar verme. Yönetim kararlarını geliştirmek için teori ve yöntemler. Öğretici. - M.: MarT, 2005. - 496 s. Yönetim kararlarının geliştirilmesi - M.: "Delo" Yayınevi, 2004 - 392 s. G. Uzman değerlendirmeleri ve karar verme - M.: Patent, 1996. - 271 s. Taha // Yöneylem Araştırmasına Giriş = Yöneylem Araştırması: Giriş. - 7. baskı. - M .: “Williams”, 2007. - S. 549-594. G. Theil. Ekonomik tahminler ve karar verme. M .: “İlerleme” 1970. K. D. Lewis. Ekonomik göstergeleri tahmin etme yöntemleri. M .: “Finans ve İstatistik” 1986. G. S. Kildishev, A. A. Frenkel. Zaman serisi analizi ve tahmini. M.: “Statistics” 1973. O. Kim, C.W. Muller, U.R. Klekka ve diğerleri.Faktör, diskriminant ve küme analizi. M.: “Finans ve İstatistik” 1989. Etkili yönetici. Kitap 3. Karar verme. – MIM LINK, 1999 Turevsky ve bir motorlu taşıt işletmesinin yönetimi. - M.: Yüksekokul, 2005. , ; tarafından düzenlendi . Yönetimde sistem analizi: öğretici. – M.: Finans ve İstatistik, 2006. , Tinkov: ders kitabı. – M.: KNORUS, 2006.
Entegre yönetim sistemlerinde iş süreçlerinin modellenmesi
İş süreçleri hangi ilkelere göre ayırt edilir? İş süreçlerinin bütünsel bir tanımının sorunu nedir? Sistem nedir, hangi özelliklere sahiptir? İş süreci modellemede sistem analizinin rolü? Bir kontrol nesnesi olarak süreç. Süreç ortamı. Bir iş sürecinin temel unsurları. Fonksiyonel ve süreç yönetiminin avantajları ve dezavantajları. PDCA yönetim döngüsü. Süreç yönetimi döngüsünün aşamaları. PUKÖ döngüsü ve ISO 9001:2008 gereksinimlerinin uygulanması. SADT metodolojisi (Yapısal Analiz ve Tasarım Tekniği - yapısal analiz ve tasarım yöntemi). Öz. Temel hükümler. IDEF0 metodolojisinde fonksiyonel aktivite modeli nasıl temsil ediliyor? Fonksiyonel model diyagramlarındaki aktiviteler ne anlama geliyor, IDEF0 metodolojisine göre nasıl görüntüleniyor? Fonksiyonel model diyagramlarındaki oklar ne işe yarar, türleri ve çeşitleri nelerdir? DFD metodolojisi. Öz. DFD diyagramlarının temel bileşenleri. DFD diyagramlarının özellikleri nelerdir ve bunlarda neler anlatılmaktadır? DFD diyagram nesnelerinin özellikleri nelerdir? DFD diyagramındaki oklar ne anlama geliyor? IDEF3 metodolojisi. Öz. Dokümantasyon ve modelleme araçları. IDEF3 diyagramlarının özellikleri nelerdir ve bunlarda neler anlatılmaktadır? IDEF3 diyagram nesnelerinin özellikleri nelerdir? Peki ya tetikçi? Süreçlerin sınıflandırılması. Tipik iş süreçleri. Yeniden yapılanma ve teknolojisi. Bir şirketi yönetirken değişim mühendisliğinin kullanılması ne zaman tavsiye edilir? İzleme ve ölçme süreçleri. Organizasyonel süreçlerin göstergeleri. Süreçlerin sayısal ve derecelendirme değerlendirmeleri."AllFusion Process Modeler (BPwin 4.1) Dialog-MEPhI ile iş süreçlerinin modellenmesi" 2003 "AllFusion Modeling Suite ile bilgi sistemleri oluşturma" ed. "Dialog-MEPhI" 2003 "AllFusion Process Modeler 4.1 ile fonksiyonel modelleme uygulaması. (BPwin) Nerede? Neden? Nasıl?" ed. "Dialogue-MEPhI" 2004 AllFusion Process Modeler (BPwin) ile Dubeykovsky modellemesi. ed. "Dialogue-MEPhI" 2007 D. Mark, K. McGowan "Yapısal analiz ve tasarım SADT Metodolojisi" SADT metodolojisi üzerine 1993 tarihli klasik çalışma. Sistemlerin Cheremnykh analizi: IDEF teknolojileri, Sistemlerin modellenmesi ve analizi. IDEF teknolojileri. Atölye. M.: Finans ve İstatistik, 2001. “Yapısal iş modelleri: DFD teknolojileri” http://www. /Level4.asp? ItemId=5810 "İş sürecinin yeniden düzenlenmesi teorisi ve uygulaması" 2003/ P50.1.. Fonksiyonel modelleme metodolojisi. M.: Rusya'nın Gosstandart'ı, 2000. http://www. IDEF0, IDEF3, DFD http://www. BPwin kullanarak iş süreçlerini modelleme http://www. /department/se/devis/7/ IDEF0 iş yönetimi süreçlerinin modellenmesinde http:///content/view/21/27/ http://www. /dir/cat32/subj45/file1411/view1411.html http://www. http://www.
Yazılım ürünlerinin etkililiğinin değerlendirilmesi
1. BT mimarisi
2. Yönetim süreçlerinin alanları.
3. Planlama ve Organizasyon alanındaki süreçlerin listesi
4. Etki Alanı Süreçlerinin Listesi Edinme ve Uygulama
5. İşletme ve Bakım alanındaki süreçlerin listesi
6. İzleme ve Değerlendirme Alanındaki Süreçlerin Listesi
7. Süreç olgunluk modelinin seviyelerinin özellikleri
9. KPI ve KGI'nın ilişkisi ve amacı
1. 10.Genel BT kontrolleri ve uygulama kontrolleri. İşletme ve BT'nin sorumluluk alanları ve sorumlulukları.
Cobit 4.1 Rusça baskısı.
Fikri mülkiyetin yaratılması ve kullanılmasına ilişkin yasal düzenleme
1. Fikri faaliyet sonuçlarına ilişkin fikri hakları listeleyin ve içeriğini açıklayın.
2. Münhasır hakların elden çıkarılmasına ilişkin anlaşma türlerini listeler. Münhasır hakların elden çıkarılmasına ilişkin bu anlaşmaların her birini açıklayın.
4. Telif hakkı nesnesi olarak bir Bilgisayar Programının yasal olarak korunmasına ilişkin ana hükümleri tanımlayın.
5. Bir telif hakkı nesnesi ve ilgili hakların bir nesnesi olarak Veritabanının yasal korumasına ilişkin ana hükümleri karşılaştırın.
6. Patent hakkı nesnelerinin patentlenebilirliğine ilişkin koşulları açıklayın: buluşlar; faydalı modeller; endüstriyel tasarımlar.
7. Bir buluş için patentlenebilirlik kriterlerinin içeriğini genişletmek: yenilik; Yaratıcı adım; endüstriyel uygulanabilirlik.
8. Bir buluş, faydalı model veya endüstriyel tasarım için patent alma şartlarını ve prosedürünü, ayrıca patentlerin geçerliliğini sağlayan koşulları ve geçerlilik sürelerini açıklayın.
9. Üretim sırlarının yasal korumasının ortaya çıktığı ve gerçekleştirildiği "know-how" ı tanımlayın ve oluşturulması sırasındaki koşulları listeleyin.
10. Korunan bireyselleştirme araçlarını listeleyin ve karşılaştırmalı özelliklerini verin.
1. Fikri mülkiyet hakları Rusya Federasyonu, ders kitabı // M, Prospekt, 2007
2., Fikri Mülkiyet Hukuku, ders kitabı // M, RIOR, 2009.
Proje ve yazılım geliştirme yönetimi [I]
Metodoloji nedir, neden gereklidir? Metodolojinin genel yapısı, metodolojinin ana unsurları. Kendi metodolojinizi tasarlama ilkeleri. Çeşitli eserlere, rollere, yeterliliklere, sınır koşullarına örnekler. Cowburn'e göre metodolojinin yapısı, metodoloji metrikleri. Cowburn'ün tasarım kriterleri. Bir metodoloji seçme kriterleri, Cowburn matrisi. Proje yaşam döngüsü. Şelale ve yinelemeli yaşam döngüsü modelleri. Şelale ve yinelemeli modellerin uygulanabilirlik sınırları. Yinelemeli metodolojinin bir örneği olarak RUP. RUP'un temel kavramları, uygulanabilirlik sınırları. Yazılım geliştirmede insanın rolü. Çevik metodolojiler, çevik metodolojilerin temel ilkeleri. Esnek metodolojilerin ortaya çıkmasının nedeni. Esnek metodolojinin bir örneği olarak Scrum. Scrum'daki roller, eserler, aktiviteler. Scrum'ın uygulanabilirlik sınırları. Ekstrem Programlama (XP) Fikirleri, değerler, temel uygulamalar, uygulanabilirliğin sınırları. Scrum ve XP arasındaki benzerlikler ve farklılıklar. Gereksinimlerin toplanması ve yönetimi. Temel uygulamalar, terimler, ilkeler. Bir projeyi ve ürünü belgelemeye yönelik yaklaşımlar, ana belge türleri. Kursta tartışılan metodolojilerden gereksinim yönetimi uygulamalarına örnekler. Yazılım geliştirme planlaması. Plan türleri, risk yönetimi, popüler riskler. Derste tartışılan metodolojilerden kalkınma planlama uygulamalarına örnekler. Yazılım geliştirmede test. Bir yazılım ürününün montajı (derlenmesi) kavramı. Temel test yöntemleri, terimler. Kursta tartışılan metodolojilerden test uygulamalarına örnekler. Montaj (derleme) kavramı, kod saklama yöntemleri, araçlar. Sürüm kontrol sistemiyle çalışmayı organize etmenin iki ilkesi. Farklı ürün kategorileri için ürün piyasaya sürme/teşhir sürecinin özellikleri, uygulama örnekleri. Yazılım mimarisinin modern kavramları, çok seviyeli mimariler, mimari kriterleri. Yazılım tasarlarken gerekli kararların listesi, veri depolama sistemi seçimine yönelik yaklaşımlar.Kent Beck - Ekstrem Programlama Frederick Brooks - Efsanevi Adam-Ayı veya yazılım sistemlerinin nasıl yaratıldığı. Tom DeMarco - Son tarih. Proje yönetimi hakkında bir roman. Tom De Marco, Timothy Lister - Ayılarla Vals. Tom de Marco, Timothy Lister - İnsan faktörü_ başarılı projeler ve ekipler. Alistair Cowburn - Her projenin kendi metodolojisi vardır. Alistair Cowburn – İnsanlar doğrusal olmayan ve yazılım oluşturmanın en önemli bileşenleridir. Andriy Orlov - Bir otomasyon mühendisinin notları. Mesleki itiraf. Philipp Kratchen - Rasyonel Birleşik Sürece Giriş. Henrik Kniberg - Scrum ve XP: ön saflardan notlar. Kurstaki derslerin sunumları
