Peki "Teknik Görev" nedir? Mükemmel teknik görevi yazma deneyimi

belgede" teknik görev"(kısalt. TK) aşağıdaki bilgileri içerir: Programın amacı ve kapsamı, program için teknik, tekno-ekonomik ve özel gereksinimler, gerekli geliştirme aşamaları ve koşulları, test türleri.

GOST'a göre, bu standart (Kasım 1987'de yeniden yayınlandı), amaçları ve kapsamları ne olursa olsun, bilgisayarlar, kompleksler ve sistemler için bir program veya yazılım ürününün geliştirilmesi için teknik şartnamelerin oluşturulması ve yürütülmesi prosedürünü belirler.
Oluştururken son derece dikkatli ve dikkatli olmalıyız, çünkü. genellikle ustaca (ve yetkin bir şekilde) hazırlanmış Görev Tanımı, tüm işlerin başarısını belirler. Genellikle mümkün olduğu kadar çok çelişkili ve aşırı gereksinimler getirmeye çalışan Müşteri ile üzerinde anlaşmaya varılan Görev Tanımı'dır. Uygulayıcının görevi ise tam tersine hayatı kendisi için kolaylaştırmaktır. Ancak her iki taraftaki imzalar atıldıktan sonra, herhangi bir şeyi yeniden oynatmak için çok geç.

Genel Hükümler

Görev tanımı, kural olarak sayfanın alanları doldurulmadan A4 ve / veya A3 formatındaki sayfalarda düzenlenir. Sayfaların (sayfaların) sayısı, metnin üstündeki sayfanın üst kısmına yapıştırılmıştır.
Bir program veya yazılım ürünü geliştirmenin sonraki aşamalarında teknik altyapıda değişiklik ve eklemeler yapmak için ek yayınlanır. Görev tanımına eklemenin koordinasyonu ve onayı, görev tanımı için belirlenen şekilde gerçekleştirilir.
Görev tanımı aşağıdaki bölümleri içermelidir:

• isim ve kapsam;
• geliştirme temeli;
• geliştirme amacı;
• program veya yazılım ürünü için teknik gereksinimler;
• teknik ve ekonomik göstergeler;
• gelişim aşamaları ve aşamaları;
• kontrol ve kabul prosedürü;
• uygulamalar.

Programın veya yazılım ürününün özelliklerine bağlı olarak bölümlerin içeriklerinin netleştirilmesine, yeni bölümler getirilmesine veya bazılarının birleştirilmesine izin verilir.

Bölüm: Ad ve kapsam

Bölümde İsim ve kapsam adını belirt kısa açıklama program veya yazılım ürününün kapsamı ve program veya yazılım ürününün kullanıldığı tesis.

Geliştirme temeli bölümünde, aşağıdakiler belirtilmelidir:

• geliştirmenin gerçekleştirildiği belge (belgeler);
• bu belgeyi onaylayan kuruluş ve onay tarihi;
• isim ve (veya) sembol geliştirme konuları

Örneğin, eğitim sürecinin özellikleriyle ilgili olarak, kurs tasarımı ödevi, __.__ tarihli enstitü emri temel alınabilir. N ___. için, sözleşme __.__. N ___., vb. için

Bölüm: Geliştirmenin amacı

Bölümde geliştirme amacı program veya yazılım ürününün işlevsel ve operasyonel amacı belirtilmelidir. Burada kendinizi bir veya iki cümle ile sınırlayabilirsiniz. Ana şey, bu programın ne için olduğunu açıkça tanımlamaktır.

Örneğin: Program, sürekli geliştiricinin otomatikleştirilmiş iş istasyonunun (AWP) çekirdeğidir. lineer sistemler kullanıcının basit modelleri analiz etme problemlerini çözmesini sağlayan otomatik kontrol sistemi (ACS).

Bölüm: Program veya yazılım ürünü için teknik gereksinimler

Bu bölüm aşağıdaki alt bölümleri içermelidir:

• performans gereklilikleri;
• güvenilirlik gereksinimleri;
• kullanım Şartları;
• teknik araçların bileşimi ve parametreleri için gereklilikler;
• bilgi ve yazılım uyumluluğu gereksinimleri;
• etiketleme ve paketleme gereksinimleri;
• nakliye ve depolama gereksinimleri;
• özel gereksinimler.

Başka bir deyişle, ayrıntılar burada başlar. Programın ne yapması gerektiğini ve nasıl görünmesi gerektiğini açıklar.

Bölüm: İşlevsel özellikler için gereklilikler.

Burada, gerçekleştirilen işlevlerin bileşimi, girdi ve çıktı verilerinin organizasyonu, zamansal özellikler vb. için gereksinimler belirtilmelidir.

Örneğin : Program izin vermelidir ... hesaplamak için ... oluşturmak için ... oluşturmak için ...

İlk veriler: belirli bir ...

Çıktı verileri: grafiksel ve metinsel bilgiler - sistem analizinin sonuçları ...; metin dosyaları - raporlar ... sistemin durumunu tanılama ve meydana gelen hataları bildirme.

güvenilirlik gereksinimleri. Güvenilir çalışmayı sağlamak için gereksinimler (kararlı çalışmanın sağlanması, giriş ve çıkış bilgilerinin kontrolü, arıza sonrası kurtarma süresi vb.) belirtilmelidir.

Burada bir şeyi "tahmin etmek" zor. En iyi durumda, programınızın yalnızca kesinlikle doğru verilerle çalıştığı bir varyant geçebilir. Genellikle Müşteri bunu kabul etmez, ancak deneyebilirsiniz.

Örneğin: Program, çalışma algoritmasına uygun olarak incelenen grafiğin belirli bir genişletilmiş insidans matrisi ile çalışmalı, ilk veriler yanlış belirtilirse hata mesajları vermeli, kullanıcıya sağlanan yetenekler çerçevesinde etkileşimli modu desteklemelidir. .

Kullanım Şartları. Hizmet türünün yanı sıra belirtilen özelliklerin sağlanması gereken çalışma koşulları (ortam hava sıcaklığı, bağıl nem, seçilen veri taşıyıcı türleri için) belirtilmelidir, Gerekli miktar ve personel nitelikleri.

Bu noktada, genellikle zorluklar ortaya çıkmaz. Ne yazık ki, kullanıcının profesyonelliği ile ilgili nokta, Müşteri tarafından zorunlu olarak ima edilmektedir. Bu, elbette, programınızda hata bulmak için başka bir nedendir. Ancak burada kendinizi "Programın çalışma koşulları IBM PC ve uyumlu PC'lerin çalışma koşullarıyla örtüşüyor", "Program profesyonel olmayan bir kullanıcı için tasarlanmalıdır" gibi ifadelerle sınırlayabilirsiniz. ve benzeri.

Teknik araçların bileşimi ve parametreleri için gereklilikler. Teknik özelliklerin bir göstergesi ile gerekli teknik araçların bileşimini belirtin.

Buradaki en önemli şey, bir yandan hiçbir şeyi unutmamak ve her şeyi önceden görmektir (aksi takdirde tek renkli ekranlı ve faresiz bazı IBM PC / XT'leri kaydırırlar) ve diğer yandan fazla ileri gitmeyin. artan gereksinimler, aksi takdirde Müşteri daha uzlaşmacı bir Yüklenici bulacaktır.

Örneğin: EGA (VGA) grafik bağdaştırıcısına sahip IBM PC uyumlu bir bilgisayara ihtiyacınız var. Gerekli disk alanı en az 600 Kb, boş RAM miktarı en az 400 Kb'dir. Bir EMS sürücüsüne ve bir fareye sahip olunması arzu edilir.

Bilgi ve yazılım uyumluluğu gereksinimleri. Özellikler önceki paragraftaki ile aynıdır. Burada giriş ve çıkıştaki bilgi yapılarının gereksinimleri ve çözüm yöntemleri, kaynak kodları, programlama dilleri belirtilmelidir. Gerektiğinde bilgi ve programlar korunmalıdır.

Örneğin: Program, MS DOS sürüm 3.3 veya üstü altında otonom olarak çalışmalıdır. temel dil programlama - Turbo Pascal 6.0.

Etiketleme ve paketleme gereksinimleri ile nakliye ve depolama gereksinimleri oldukça egzotiktir. Genel durumda, bir yazılım ürününü etiketleme gereksinimleri, seçenekler ve paketleme yöntemleri burada belirtilir. Taşıma ve depolama gereksinimlerinde ise yazılım ürünü için taşıma koşulları, depolama yerleri, saklama koşulları, depolama koşulları, çeşitli koşullarda saklama süreleri belirtilmelidir.

Özel gereksinimler çok sorumlu bir şeydir. Onlardan mümkün olduğunca kaçınmak en iyisidir. Ve hemen duyurun.

Örneğin: Programın zaman özellikleri için özel bir gereklilik yoktur. Programın kapasitif özellikleri için özel gereksinimler yoktur.

Teknik ve ekonomik göstergeler. Bir programcı için bu en zor öğe her zaman orada değildir. Öncelikle, amacınız yapılan işin muazzam etkinliğini ve önemini haklı çıkarmak olduğunda gereklidir. Bu öğe genellikle Müşteri için çok iyi çalışır. En azından bu, geliştirmenin zamanlaması ve maliyeti için en iyi gerekçedir.

Bu bölüm şunları belirtmelidir: tahmini ekonomik verimlilik, tahmini yıllık ihtiyaç (örneğin: bir bütün olarak komplekse yapılan tahmini çağrı sayısı yılda 365 çalışma seansıdır), en iyi yerli ve yabancı örneklere kıyasla geliştirmenin ekonomik avantajları veya analoglar.

Ek olarak, hem bir program geliştirmenin tahmini maliyetinin hem de programlamanın karmaşıklığının tanımının verilmesi arzu edilir.

Geliştirme aşamaları ve aşamaları (bu aşağıda daha ayrıntılı olarak tartışılacaktır), gerekli geliştirme aşamalarını, aşamaları ve işin kapsamını (geliştirilmesi, üzerinde anlaşmaya varılması ve onaylanması gereken program belgelerinin bir listesi) ve kural olarak belirler. , geliştirme zaman çizelgesi ve icracıları belirleyin.

Standart adımlar burada açıklanmıştır. Ana şey, zamanlamayı doğru bir şekilde belirlemektir. Mümkünse, aşamaları zamana (ve miktara) göre eşit şekilde dağıtmaya çalışın. Tüm projelerin son aşamaya gelmediğini unutmayın. Ve raporlar her aşamada olmalıdır. Çalışan projenin en fazla zamanı alacağını da unutmayın. Belgeleri zamanında tamamlamak için zamanınız yoksa, Müşteri tam sağ bundan sonraki tüm sonuçlarla birlikte işi hiç kabul etmeyin.

Ana ve vazgeçilmez aşamalar ve aşamalar, görev tanımının kendisi, taslak tasarım, teknik ve çalışma tasarımlarıdır.

Ön tasarım. Bu aşamada girdi ve çıktı verilerinin yapıları ayrıntılı olarak geliştirilir, sunum biçimleri belirlenir. Algoritmanın genel bir açıklaması, algoritmanın kendisi ve programın yapısı geliştirilmektedir. Programın geliştirilmesi ve uygulanması için bir eylem planı geliştirilmektedir.

Teknik proje. Problemi çözmek için geliştirilen algoritmayı ve ilk bilgileri kontrol etme yöntemlerini içerir. Ayrıca hata işleme araçları geliştirir ve teşhis mesajları verir, başlangıç ​​verilerinin sunum biçimlerini ve teknik araçların konfigürasyonunu belirler.

Çalışma projesi. Bu aşamada, programın programlanması ve hata ayıklaması, program belgelerinin geliştirilmesi, programlar ve test yöntemleri gerçekleştirilir. Test ve hata ayıklama örnekleri hazırlanıyor. Dokümantasyon ve grafik materyal tamamlanmıştır. Programın geliştirilmesi sırasında genellikle aşağıdaki belgelerin hazırlanması gerektiği belirtilir:

Program metni;

Programın açıklaması;

Program ve test metodolojisi;

Uygulamanın açıklaması;

Kullanım kılavuzu.

Bunlar standart gereksinimlerdir. Müşteri, bu listenin tamamının sunulamayacağını kabul ederse, bu, sizinle ve ürününüzle ilgili niyetlerinin ciddi olmadığı anlamına gelir.

Grafikler mevcut olabilir veya olmayabilir. Özellikle çalışmanızın sonuçları hakkında rapor vermeyeceğiniz zaman. Ancak ciddi projeler için bu öğe gereklidir.

Örneğin: Programın geliştirilmesi sırasında aşağıdaki grafik materyal hazırlanmalıdır:

Teknik ve ekonomik göstergeler;

Program yapısı;

Programın giriş verilerinin sunum biçimi;

Algoritmanın genel şeması (2 sayfa);
o temel hesaplama algoritmaları;
programın nasıl çalıştığına dair bir örnek.

Kontrol ve kabul prosedürü bölümünde, test türleri ve işin kabulü için genel gereklilikler belirtilmelidir. Mümkünse bu paragrafta "geliştirmenin kontrol ve kabulünün Müşteri tarafından sağlanan ekipman üzerinde yapıldığını" belirtin, aksi takdirde ekipmanı yanınızda getirmeniz istenebilir.

Örneğin: Geliştirmenin kontrolü ve kabulü, kontrol ve hata ayıklama örnekleri temelinde gerçekleştirilir. Bu, tüm program işlevlerinin yürütülmesini kontrol eder.
Görev tanımının Eklerinde, gerekirse şunları belirtin:
geliştirmeyi doğrulayan araştırma ve diğer çalışmaların bir listesi;

Geliştirmede kullanılabilecek algoritma şemaları, tablolar, açıklamalar, gerekçeler, hesaplamalar ve diğer belgeler;

Diğer geliştirme kaynakları.

Geliştirme sırası kurumsal kimlik, ambalaj tasarımı, logo veya web sitesine her zaman ilgili belgelerin - bir sözleşme, bir özet ve bir teknik görev (TOR) - hazırlanması ve yürütülmesi eşlik eder. TK'nın oluşturulması, müşteri ve yüklenicinin ortak çalışmasının ilk aşamasıdır.

Maliyetleri azaltmanın ve bir projenin bütçesini azaltmanın en yaygın yollarından biri, bunu kendiniz yapmaktır. teknik özelliklerin yazılması (teknik özellikler) .

Bununla birlikte, belirli bir deneyim olmadan, hem yüklenici hem de müşteri için net olacak yetkin bir teknik şartname hazırlamak oldukça zordur.

Görev tanımında, işin amacı için gereklilikleri doğru ve net bir şekilde tanımlamak, teknik parametreleri, nesnenin amacını belirlemek, gerekli kompozisyonu hazırlamak gerekir. Proje belgeleri, işin zamanlamasını ve sırasını belirleyin.

Görev tanımının geliştirilmesine geçmeden önce araştırma yapmak, ön hesaplamalar yapmak ve ilk bilgileri toplamak gerekir.

Teknik şartnamelerin oluşturulması, en iyi profesyonellere bırakılan karmaşık bir süreçtir, ayrıca "kraliyet markanızın" teknik bir görev yazmaktan daha önemli ve öncelikli görevleri vardır.

şartname

teknik görev - bu, tüm projenin ve müşteri ile yüklenici arasındaki ilişkinin temel belgesidir; bu, iş sırasını, tarafların yükümlülüklerini ve projenin zamanlamasını açıkça tanımlamanıza olanak tanır.

Projenin bir bütün olarak zamanlaması ve başarısı, yüklenici için görev tanımlarının ne kadar doğru, doğru ve net bir şekilde hazırlandığına bağlı olacaktır.

TK türleri (referans şartları)

Görev tanımı - herhangi bir projenin uygulanmasına yönelik ilk adım. İşin performansı için sayısız teknik özellik türü vardır:
- sitenin geliştirilmesi için görev tanımı;
- logonun geliştirilmesi için görev tanımı;
- programın geliştirilmesi için görev tanımı;
- kurumsal kimliğin geliştirilmesi için görev tanımı;
- tasarım geliştirme için görev tanımı;
- şirket adının geliştirilmesi için görev tanımı;
- web sitesi tanıtımı vb. için görev tanımı

Proje yürütücüsü olarak kimi seçerseniz seçin - bir serbest çalışan veya bir marka ajansı, bir proje üzerinde çalışmaya başlamadan önce, büyük miktarda heterojen bilgiyi analiz etmeniz ve işlemeniz gerekir. Projenin amaç ve hedefleri, şirketin stratejik ve mevcut hedefleri, işin amacı için gereklilikler, müşterinin istekleri, projenin tamamlanması için son tarihler ve beklenen sonuçlar ile ilgili verileri incelemek. Ardından, bu bilgileri birlikte toplamanız, verileri yapılandırmanız ve yükleniciye teknik bir görev şeklinde sağlamanız gerekir.

Kural olarak, görev tanımının geliştirilmesi proje yöneticisinin görevidir. Müşteri dışında hiç kimse fikirleri, çalışma ilkelerini, proje hedeflerini ve şirket faaliyetlerini en iyi şekilde tanımlayamaz. Bu açıklama mümkünse olabildiğince açık olmalı ve şirket, markası hakkında genel bir hikaye şeklinde sunulmalıdır.

Görev tanımının yapısı

Görev tanımının yapısı (görev tanımının şekli) aşağıdaki gibidir:

1. Proje hedefleri
Görev Tanımında, şirketin tamamlanan projenin sonuçlarını kullanarak hangi hedeflere ulaşmak istediğini belirtmek gerekir. Bu tür hedefler, örneğin: yeni bir ürün lansmanı, bir şirket veya ticari markanın yeniden markalaştırılması, bir reklam kampanyası yürütülmesi vb. olabilir.
2. Müşterinin şirketinin açıklaması
- Şirketin faaliyet alanı ve ölçeği, misyonu ve pazardaki konumu;
- Şirketin marka portföyünün tanımı - şirketin hangi markalarla çalıştığı;
- Ana rakip şirketlerin listesi;
- Şirketin ve USP'nin (Benzersiz Satış Teklifi) ana rekabet avantajlarının listesi.
3. Durumun açıklaması ve son pazar eğilimleri markanın geliştirilmekte olduğu
- Şirketin ürün veya hizmetlerinin fiyat segmenti;
- Tüketicinin portresi (hedef kitlenin yaşı, cinsiyeti, coğrafi verileri, sosyal düzeyi);
- Şirketin taktiksel ve stratejik pazarlama hedefleri (1 ila 3 yıllık bir süre için);
- Bir tüketici davranışı modeli ve tüketicinin satın alma yaptığı durumların açıklaması;
- Yeniden markalaşma durumunda gerekli olan mevcut markanın ana özelliklerinin, konumlandırma konseptinin, sloganının, pazarlama iletişimlerinin açıklaması.
4. Referanslar
Müşterinin bu proje kapsamında beğendiği benzer çalışma örneklerinin bir listesi.
5. Gereksinimler
Bu bölümde, proje için tüm teknik ve fonksiyonel gereksinimleri belirlemek gerekir. Müşterinin ihtiyaç ve isteklerinin yanı sıra grafik, metin, renk uyumu, stil vermek, yazı tipleri,

Yazardan: Nasıl yazılır sitenin geliştirilmesi için referans şartları (TOR)? Konu oldukça kapsamlı ve bir not çerçevesinde onu% 100 ayrıştırmak zor (mümkünse). Ancak Genel Hükümler, web sitesinin teknik özelliklerini derlerken nelere dikkat etmeniz ve nelere dikkat etmeniz gerektiği hakkında, yeterince ayrıntılı olarak belirtmeye çalışacağım.

Bu nedenle, sitenin geliştirilmesi için referans şartları

Görev tanımı geliştirici için hazırlanmıştır. Müşteri ile yüklenici arasında bir sözleşme hazırlanırken TK'ya atıfta bulunulmalıdır. Puanların ve son teslim tarihlerinin yerine getirilmemesi veya yanlış yerine getirilmesi sorumluluğu her iki tarafta da belirtilmelidir. Ancak teknik görevin yaratıldığı en önemli şey (bence) proje geliştirme sürecini hızlandırmak.

Bu örneği inceleyelim:

Diyelim ki sitenizin yan tarafında bir takvime ihtiyacınız var. Önemsiz bir şey gibi görünüyordu. Ancak işlevselliğini ne kadar çok tanımlarsanız, sonucu o kadar hızlı alırsınız.

Burada biraz anlatacağım. Geçerli ayın haftanın günleri için sayıları gösteren bir takvim var. Ve aylar arasında gezinmek için bir seçenek var. Aylar ve yıllar arasında geçiş yapabilen bir takvim var.

Diyelim ki güncel tarihin vurgulandığı en son sürümü (aylar ve yıllar arasında gezinme özelliğiyle) istiyorsunuz. Görev tanımında şunu belirtmişsiniz: "kenar çubuğunda bir takvim gereklidir." Sizi ilk seçenek haline getirirler (basitçe geçerli ayın haftanın günleri için sayıları gösterir).

Neyimiz var. Yüklenici, TK maddesini yerine getirdi, ancak siz tamamen farklı bir şey istediniz. Görünüşe göre her şey uygun, suçlanacak kimse yok, çatışma çıkmadı ama en önemli şey kayboldu zaman ve para.

Bu sadece sıradan bir takvim örneğidir.

Ve takvimde olduğu gibi işlenmesi yarım günden fazla süren daha ciddi bir şeyi yeniden yapmanız gerekirse? Müteahhit, projenizi bitirip yenisini başlatabilecekken sizinle dalga geçiyor.

Bu nedenle, daha Daha her modülün işlevselliğini tanımlarsanız, sonucu o kadar hızlı alırsınız. Her iki taraf da bununla ilgilenmeli.

Genellikle hangi öğeler teknik bir görevden oluşur?

Bir şirket veya firmanın sahibi olduğunuzu düşünelim. Şirketiniz herhangi bir ürünün üretimi ve uygulanması ile uğraşmaktadır. Alıcılarınız var. Satıcılar (mağazalar ve çevrimiçi mağazalar), hizmet merkezleri, ürün tüketicileri ile işbirliği yaparsınız. Ya da böyle bir firmaya kaynak yapıyorsunuz ve teknik bir görev yazmanız gerekiyor.

Hangi rolü oynarsanız oynayın, bir web sitesi tasarımı oluşturmak için teknik bir görev hazırlamadan önce yapmanız gereken ilk şey, kuruluşun yapısını, ne yaptığını, isimlendirmeyi, özellikleri ve genel olarak bağlantılı her şeyi incelemektir. ürünler ve şirket ile. Müşterinin kuruluşta olup bitenlerin özünü ne kadar derinlemesine araştıracağı, kaynakta ne olacağına bağlıdır. Bu nedenle, buradaki görev karşılıklıdır: Müşteri, işletme hakkında olabildiğince ayrıntılı bilgi vermeli ve icracı, olup bitenlerin özünü tam olarak anlamalıdır.

Projenizi yapacak şirketin görev tanımını kendiniz yazsanız bile, hepsini bir kağıt üzerinde çözmek fena değil.

Gelelim noktalara.

Tanım

Buraya şirket hakkında, ne yaptığı hakkında birkaç cümle yazabilirsiniz. Giriş gibi bir şey yapın.

Hedef kitle kimler için:

Potansiyel Alıcılar

ürün satıcıları (mağazalar, çevrimiçi mağazalar)

servis merkezleri

ortaklar (firmalar)

ürün tüketicileri (halihazırda satın almış olanlar)

Neden bir web sitesine ihtiyacınız var:

Şirketin imajını geliştirmek için

satışları artırmak

Müşteri rahatlığı için

Kurumsal

Web sitesi - kartvizit

internet dükkanı

Dil sürümleri:

İngilizce

Site bazı sorunları çözmelidir. Buna göre amaç ve hedefler doğrultusunda ilerliyoruz.

Amaçlar ve hedefler

Görev tanımının bu bölümünde, tüm hedef kitleyi inceliyoruz ve sitenin onlar için çözmesi gereken görevleri açıklıyoruz.

Ürünlerin potansiyel alıcıları.

Hedef: daha fazla alıcı çekin ve onları ilk satın alma işlemini yapmaya ikna edin, bir seçim yapmanıza yardımcı olun.

Çözülmesi gereken görevler:

Ürünler hakkında yüksek kaliteli, kapsamlı bilgi sağlamak, ek hizmetler, garanti, servis, seçim yöntemleri.

Mağazalar hakkında bilgi gönderin

perakende bilgileri sağlayın ticaret ağı

Ürünlerin seçimi, satın alınması konusunda işletme uzmanları tarafından potansiyel alıcılara çevrimiçi danışmanlık organizasyonu yoluyla soru sorma fırsatı sağlayın.

Böylece hedef kitlenin tamamını gözden geçiriyoruz. Ayrıca ürün satıcıları (mağazalar, çevrimiçi mağazalar), hizmet merkezleri, ortaklar (şirketler), ürün tüketicileri için amaç ve hedefleri açıklıyoruz. Yani, sitenin her biri için özel olarak yapması gereken şey.

Şimdi modülleri listeleyelim.

Site işlevselliği

İşlevselliği listelemek için neye ihtiyacı olduğuna karar vermeniz gerekir:

kayıt gerekli mi

Kapalı bir bölüme ihtiyacım var mı (sadece kayıtlı kullanıcılar için)

bir forma ihtiyacın var mı geri bildirim

Vesaire. ve benzeri.

Web geliştirmede modern eğilimler ve yaklaşımlar

Web sitesi oluşturmada sıfırdan hızlı büyüme için algoritmayı öğrenin

Tüm bunları anlattıktan sonra, en önemli ve ilginç olana geliyoruz. Elbette yukarıda yapılan tüm işler çok önemli ama şimdi daha da "sıcak" oluyor.

işlevsellik açıklaması

Açık şu an sitenin kimin için olduğunu, hangi hedefleri ve görevleri yerine getirmesi gerektiğini, ek işlevsellik.

Toplanan tüm bilgileri bir sisteme getirmeniz ve güzelce koymanız gereken zaman geldi. İşi kolaylaştırmak ve tekerleği yeniden icat etmemek için benzer konulardaki kaynaklara bakabilirsiniz. Onlardan bir şeyler öğrenin, işlevlerini görün ve test edin ve projenizde uygunsuz görünen şeyleri iyileştirmeye çalışın. Prensip olarak, görev tanımının hazırlanmasının en başında benzer konuların bulunduğu sitelere bakabilirsiniz (ve hiç deneyiminiz yoksa, o zaman buna bile ihtiyacınız vardır).

Menü öğeleriyle başlamanızı öneririm. Ana sayfaları görüntülemesi ve her ziyaretçinin kendisi için hızlı bir şekilde bilgi bulmasını sağlaması gerekir. Ve ziyaretçiler bizim hedef kitlemizdir. Menü birçok öğe içerecek, bu nedenle bir açılır liste şeklinde olacaktır.

İlk önce şirket hakkında bilgi vermelisin. Şirket, şirket geçmişi, kişiler, incelemeler hakkında sayfalar olabilir.

Doğal olarak, "ürünler" menü öğesi ve "ürün kataloğu", "sürümler", "ürün incelemeleri" alt öğeleri olmalıdır.

Genel olarak, umarım nasıl boyanacağı açıktır. Olası menünün son halini sunacağım:

Şirket hakkında

şirketin tarihi

kişiler

ürünler

Ürün kataloğu

ürün yorumları

servis bölümü

Garanti hizmeti

garanti sonrası servis

tüketici

satın alma ve teslimat

kullanmak

hizmet hakkında

mağazalar ve çevrimiçi mağazalar

ürün fotoğrafları

SSS

servis merkezleri

Nasıl servis merkezi olunur

SSS

ortaklar

işbirliğine davet

SSS

Menüyü bir nevi çözdük. Şimdi her sayfada ne olacağını ve bir bütün olarak nasıl çalıştığını açıklamanız gerekiyor. Ayrıca kaba bir düzen sağlar. Kalemle bir kağıda çizilebilir, taranabilir ve iş tanımına eklenebilir. Söyleyeceğim tek şey, tasarımcının hayal gücünü sınırlamayın, onu en genel haliyle çizin.

Bu kısım, sayfanızın nasıl görünmesini istediğinize bağlı olarak değişir. Belki üstte çok fazla başlığa ihtiyacınız yok, belki üstte kişileri (adres, telefon, faks) belirtmeniz gerekiyor, belki "site haritası", "ev", "kişiler" simgeleri şeklinde. Belki solda haberlere ihtiyacınız yoktur, ancak solda "promosyonlar ve sürümler"i gösterin.

Şimdi asıl mesele işin mantığını anlatmak.

operasyon mantığı

Yukarıdaki şekle göre anlatacağım.

Üst kısım (başlık) her sayfada aynı kalır. Haber akışı yalnızca ana sayfada görünür. Soldaki ikincil sayfalarda, şu anda içinde bulunduğumuz öğenin menü alt öğelerini gösteririz (örneğin, "servis" sayfasındaysak, "garanti servisi", "gönderi" bağlantılarını gösteririz. -Garanti hizmeti"). Buna göre, bu bağlantılardaki geçişler ilgili sayfalara yönlendirir. Burada, soldaki alt öğeler altında, çevrimiçi danışmanlarla (Skype, ICQ) iletişim kurmak için verileri görüntülüyoruz. Blok promosyonları ve yayınları her sayfada kalır. Alt bilgi (alt bilgi) her sayfada aynı şekilde görüntülenir.

Yaklaşık olarak işin genel mantığı böyle anlatılır.

Şimdi, sitenin geliştirilmesi için TK'mızda, sitenin belirlenmiş her bir bloğunu ayrıntılı olarak açıklıyoruz. Örneğin, "Haber akışı".

En son 10 haberden oluşan "Haber akışı". Her haber, haber başlığı, yayın tarihi, haberin kısa bir başlangıcı (4-5 satır) ve "tam oku" linkinden oluşmalıdır. "Tamamını oku" bağlantısına tıklayarak haber sayfasına ulaşıyoruz. Vurulan haberler, ana içeriğin yerine görüntülenir. Ayrıca haberin başlığını, yayın tarihini içerir. Haber akışı da solda görüntülenir. Geçmiş ay ve yıllara ait haberler arşivlenir. Yani içinde bulunduğumuz aya ait haberlerin altında “(falan ay veya yıl) için bir arşiv” gösteriyoruz. "Arşiv (böyle bir ay veya yıl)" bağlantısını tıkladığınızda, ilgili ay / yıl için bir haber listesi çıkar.

Her bloğun çalışmasını bu şekilde açıklıyoruz. Takvim olayını unutmayalım. Ve en önemlisi, ürün kataloğunun çalışmalarını boyamanız gerekiyor. İşte size bir görev veriyorum: kataloğun nasıl çalışacağını düşünmeye ve açıklamaya çalışın. Seçeneklerinizi e-posta ile gönderin. En iyisini yayınlayacağız.

Başka ne olmalı? Uyumluluğu belirtmek güzel olurdu.

Uyumluluk

Sitenin oluşturulmasına ilişkin yönergelerimizin bu paragrafında, web sitesinin hangi işletim sistemlerinde ve hangi tarayıcılarda eşit derecede iyi görünmesi gerektiğini belirtiyoruz. Hangi versiyonda, hangi dilde yazılmalıdır. Hangi CMS kullanılıyor? Ne hakkında konuştuğunuzu gerçekten anlıyorsanız, belirtmeye değer.

Bu sorulara sahip değilseniz, sitenin doğru şekilde görüntülenmesi gereken tarayıcıları belirtmeniz yeterlidir. Geri kalanı için, icracının vicdanına güvenin.

Çözüm

Bu yazıda, TK'nin bu şekilde derlendiğini ve başka bir şey olmadığını göstermeye çalışmadım. Bunu yapın ve herhangi bir sorun yaşamayacaksınız. bir kalite derleyin web sitesi geliştirme için referans şartları daha çok bir soru deneyim. İlk çiftte, herkes yetkin bir teknik görev hazırlayamayacaktır.

Bu yazıda, bir web sitesinin tasarımının ve mantığının geliştirilmesi için bir iş tanımı örneğinin oluşturulduğu bir örnek ve ilkelerin yanı sıra dikkat etmeniz gereken ana noktaları göstermek istedim. Ne kadar başarabildim, umarım yorumlarınızdan öğrenirim.

Ve meydan okumayı unutma!

Öncelikle, görev tanımının (TOR) sitenin geliştirilmesi için Sözleşmenin ayrılmaz bir parçası olan resmi bir belge olduğu hatırlanmalıdır.

İş Tanımı, geliştirme için teknik gerekçeyi ve öngörülen saha için gereklilikleri (tasarım, navigasyon, bilgi sunma yolları) içerir; geliştirmenin her aşaması için zamanlamayı, maliyeti, kapsamı ve prosedürü belirler.

Görev tanımı, Müşteri ve Yüklenici tarafından iki taraflı olarak onaylanan ilk saha tasarım belgesidir. TK, geliştirmenin gerçekleştirildiği ve nihai ürünün kalitesinin değerlendirildiği temel belgedir.

İş Tanımı temelinde, Müşterinin Yüklenicinin işinin kalitesine ilişkin talepleri kabul edilir veya reddedilir, tamamlanan iş için ödeme yapılır ve bir kabul sertifikası verilir.

bikeriderlondon/Shutterstock.com

Görev tanımı, Yüklenici tarafından tamamlanmış bir özet, ön çalışmaların sonuçlarının analizi, hesaplamalar ve gelecekteki sahanın tasarım modellemesi temelinde derlenir. TK, gelecekteki sitenin tüm gereksinimlerini, yönlerini ve ayrıntılarını dikkate almalıdır.

Bu belge, sitenin uygulanması için eksiksiz bir gereksinim seti sağlar.

Müşteri ve Yüklenici aynı fikirde

Müşterinin ve Yüklenicinin bu belgedeki imzası, aşağıdaki gerçekler ve koşullarla anlaşmalarını teyit eder:

1. Yüklenici, yapılan iş için gereksinimlerin bir listesini içeren Görev Tanımı (TOR) adı verilen bu belgeyi hazırlamış ve geliştirmiştir.
2. Müşteri, bu Görev Tanımının tüm hükümlerini kabul eder.
3. Görev Tanımının onaylanmasından sonra, önceki tüm sözleşmeler geçersiz hale gelir ve yalnızca bu Görev Tanımının maddeleri geçerlidir.
4. Müşteri, mevcut Sözleşme kapsamında Yükleniciden işbu İş Tanımında doğrudan açıklanmayan işlerin yapılmasını veya hizmetlerin sağlanmasını talep etme hakkına sahip değildir.
5. Yüklenici, yalnızca bu Görev Tanımında belirtilen işi gerçekleştirir.
6. İşbu Görev Tanımı'nın madde kapsamını aşan her şey, taraflarca onaylanan bu Görev Tanımı'na yapılan eklemelere göre Müşteri tarafından ayrıca ödenir.
7. Yüklenici, görev tanımının yazılı olarak onaylanması, görev tanımında belirtilen gerekli tüm bilgilerin alınması, müşteriden gerekli malzemelerin alınması ve ödeme noktalarının yerine getirilmesinden sonra görev tanımı üzerinde çalışmaya devam eder.
8. Müşteri, işi tamamlandıktan sonra 3-5 iş günü içinde teslim almayı, iş tamamen ve İş Tanımına uygun olarak tamamlanmışsa, bu Görev Tanımında belirtilen süre içinde işin bedelini ödemeyi taahhüt eder.
9. Müşteri, bu İş Tanımında belirtilmedikçe, Yükleniciden herhangi bir format ve standarda uymasını talep etme hakkına sahip değildir.
10. Sitenin oluşturulması ile ilgili tüm çalışmalar Yüklenicinin kendi barındırmasında gerçekleştirilir. Tüm çalışmalar tamamlandıktan sonra test için gerçek bir sunucuya aktarılır.
11. İşin tamamlanmasının ardından, Yüklenici 5 iş günü içinde, ancak günde yarım saatten fazla olmamak üzere idare ile ilgili istişarelerde bulunur. Ek süre, Yüklenicinin güncel tarifelerine göre ayrıca ödenir.
12. İmzalandıktan sonra bu İş Tanımında tanımlanan tüm belirsizlikler, Taraflar arasındaki ikili anlaşmaya tabidir. Onay sürecinde, hazırlanan ek gereksinimler geliştirilebilir. Ek anlaşma Anlaşmaya göre değerlendirilir ve buna göre değerlendirilir.
13. Bu belgenin hükümleri, belirtilen şekilde onaylandıktan sonra geliştiriciler için bağlayıcıdır.
14. TK, yapılan işi doğrulamanın bir yoludur.

İlgili makale: 10 faydalı ipuçları site oluştururken

Tarayıcı Uyumluluğu

Ziyaretçilerin kullanması muhtemel çeşitli tarayıcıların işlevselliğine dikkat edilmelidir. Sitenin aynı şekilde görüntülenmesini sağlamak için en popüler tarayıcılarla uyumluluğu sağlamanız gerekir:

• Internet Explorer (sürüm 8 ve üstü);
• Mozilla Firefox (sürüm 3 ve üzeri);
• Google Chrome (sürüm 4 ve üstü);
• Opera (sürüm 10 ve üstü).

Web sitesi sayfa düzeni gereksinimleri

Metin okunabilir olmalıdır. İstatistiklere göre, minimum ekran çözünürlüğü kullanıcı monitörleri 1024×768 pikseldir. Bu çözünürlükte, sitedeki tüm metinler net görünmelidir ve yatay kaydırma çubuğu kullanılmadan net bir şekilde görünür olmalıdır. 1024x768'den düşük çözünürlüklerde yatay bir kaydırma çubuğu görünecektir.

Yüksek çözünürlüklü monitörlerde iyi görünmesi için sitenin maksimum boyutta da sınırları olmalıdır. Bu yüzden maksimum site genişliği 1280x1024 olacaktır.

Site İçeriği Değişiklik Gereksinimleri

Uzaktan yönetim için (metin ve grafik bilgilerinin eklenmesi, düzenlenmesi ve silinmesi) kullanılabilir. ücretsiz sistem WordPress gibi içerik yönetim sistemi (CMS). Ancak UMI.CMS'yi de kullanabilirsiniz (kullanıcının siteyi düzenlemesi daha uygundur, ancak geliştirici için daha zordur). Bu nedenle, Müşteri UMI.CMS'yi kullanmak isterse, tasarımın onaylanmasından sonra uygulama maliyeti ayrıca görüşülür. Yaklaşık olarak programlama maliyetinin %50'si kadar daha pahalı olacaktır.

CMS yardımıyla kolayca yeni bölümler ve alt bölümler ekleyebilirsiniz, ancak aynı zamanda veritabanının içeriklerini yönetmenin yanı sıra sitenin görünümünü değiştiremezsiniz.

Özet

Site geliştiricisinin karşı karşıya olduğu görevleri ne kadar ayrıntılı tanımladığınıza bağlı olarak, projeyi teslim etmek çok daha kolay olacaktır. Resmin açılır pencerede nasıl açılacağını, hangi çerçevede olacağını ve bazı ek efektlerle açılıp açılmayacağını yazmaya kadar. Çoğu zaman müşteriler, bir site oluştururken bile metin, resim vb.

Bana sık sık şu soru sorulur: "Otomatik bir sistem için teknik bir görev nasıl geliştirilir?". Benzer bir konu çeşitli forumlarda sürekli olarak tartışılmaktadır. Bu soru o kadar geniştir ki kısaca cevaplamak imkansızdır. Bu nedenle, bu konuda uzun bir makale yazmaya karar verdim.

• İlk bölümde" Teknik özelliklerin geliştirilmesi. Nedir, neden gereklidir, nereden başlamalı ve nasıl görünmelidir?? Konuyla ilgili soruları ayrıntılı olarak yanıtlamaya, Görev Tanımının yapısını ve amacını ele almaya ve gereksinimlerin formüle edilmesine ilişkin bazı önerilerde bulunmaya çalışacağım.
• İkinci kısım " Teknik özelliklerin geliştirilmesi. Gereksinimler nasıl formüle edilir?? tamamen bilgi sistemi gereksinimlerinin belirlenmesine ve formüle edilmesine ayrılacaktır.

Öncelikle, "Teknik bir görev nasıl geliştirilir?" Gerçek şu ki, teknik şartnamelerin geliştirilmesine yönelik yaklaşım, büyük ölçüde bunun hangi amaçlarla yapıldığına ve kimler tarafından kullanılacağına bağlı olacaktır. Hangi seçeneklerden bahsediyorum?

• Ticari bir kuruluş, otomatikleştirilmiş bir sistem uygulamaya karar verdi. Kendi BT hizmeti yoktur ve bunu yapmaya karar vermiştir: İlgili kişinin İş Tanımını geliştirmesi ve geliştirme için sunması gerekir. üçüncü taraf kuruluş;
• Ticari bir kuruluş, otomatikleştirilmiş bir sistem uygulamaya karar verdi. Kendi BT hizmeti vardır. Bunu yapmaya karar verdik: bir Görev Tanımı geliştirin, ardından bunu BT hizmeti ile ilgili taraflar arasında koordine edin ve uygulayın kendi başlarına;
• Devlet yapısı bir bilişim projesi başlatmaya karar verdi. Burada her şey çok çamurlu, bir sürü formalite, rüşvet, kesinti vb. Bu seçeneği bu yazıda dikkate almayacağım.

• Bir BT şirketi, otomatik sistemlerin geliştirilmesi ve / veya uygulanmasına yönelik hizmetlerle uğraşmaktadır. Bu en çok zor durum, çünkü çeşitli koşullarda çalışmak zorundasınız:

  • Müşterinin kendi görüşleri olan kendi uzmanları vardır ve Görev Tanımı için özel gereklilikleri vardır;
  • Görev tanımı, kendi geliştiricilerimiz için geliştirilmiştir (müşteri umursamaz);
  • Görev tanımı, yükleniciye (yani şirket personeli dışından bir grup programcıya veya bireysel bir uzmana) transfer için geliştirilir;
  • Elde edilen sonuç konusunda firmalar ile müşteri arasında bir yanlış anlaşılma vardır ve firma tekrar tekrar “İş Tanımı nasıl geliştirilmelidir?” sorusunu sormaktadır. İkinci durum bir paradoks gibi görünebilir, ancak doğrudur.
  • Diğer, daha az yaygın seçenekler de mümkündür;

Bence şimdi okuyucunun soruları olmalı:

• İş Tanımı neden hep aynı şekilde geliştirilemiyor?;
• Herhangi bir standart, yöntem, öneri var mı? Onları nereden alabilirim?
• Görev Tanımını kim geliştirmeli? Bu kişinin herhangi bir özel bilgiye sahip olması gerekiyor mu?
• Görev tanımının iyi yazılmış olup olmadığı nasıl anlaşılır?
• Kimin pahasına geliştirilmeli ve hiç gerekli mi?

Bu liste sonsuz olabilir. 15 yıldır mesleki gelişimde olduğum gerçeğinden o kadar emin konuşuyorum ki yazılım ve birlikte çalışmanız gereken herhangi bir geliştirme ekibinde Görev Tanımı sorusu ortaya çıkar. Bunun nedenleri farklıdır. Görev Tanımının geliştirilmesi konusunu gündeme getirirken, konuyla ilgilenen herkese %100 sunamayacağımın farkındayım. Ama dedikleri gibi "her şeyi raflara koymayı" deneyeceğim. Makalelerime zaten aşina olanlar, başkalarının çalışmalarını "kopyala-yapıştır" kullanmadığımı, başkalarının kitaplarını yeniden basmadığımı, çok sayfalı standartlardan ve İnternette bulabileceğiniz diğer belgelerden alıntı yapmadığımı bilirler. onları parlak düşünceleriniz olarak geçiştirmek. Arama motoruna "Tanım Şartları Nasıl Geliştirilir" yazmanız yeterlidir ve pek çok ilginç, ancak maalesef birçok kez tekrarlanan birçok şeyi okuyabileceksiniz. Kural olarak, forumlarda zeki olmayı sevenler (sonuçta aramayı deneyin!), Kendileri için asla mantıklı bir Görev Tanımı yapmadılar ve bu konuda sürekli olarak GOST tavsiyelerinden alıntı yaptılar. Ve konuyla gerçekten ciddi şekilde ilgilenenlerin genellikle forumlarda oturacak vakti yoktur. Bu arada, GOST'lardan da bahsedeceğiz. İÇİNDE farklı yıllarÇalışmamda, hem bireysel uzmanlar hem de seçkin ekipler ve danışmanlık şirketleri tarafından derlenen birçok teknik dokümantasyon versiyonu gördüm. Bazen şöyle faaliyetler de yapıyorum: Kendime zaman ayırıyorum ve ilgimi çeken bir konu hakkında alışılmadık kaynaklardan bilgi arıyorum (çok az istihbarat). Sonuç olarak Gazprom, Rus Demiryolları ve diğerleri gibi canavarlarla ilgili belgeleri görmek zorunda kaldım. ilginç şirketler. Tabii ki, bu belgelerin bana kamu kaynaklarından gelmesine veya danışmanların sorumsuzluğuna (İnternet üzerinden bilgi dağıtıyorlar) rağmen, gizlilik politikasına uyuyorum. Bu nedenle derhal şunu söylüyorum: Başka şirketlere ait gizli bilgileri, kaynağı ne olursa olsun (mesleki etik) paylaşmam.

Teknik görev nedir?

Şimdi yapacağımız ilk şey, bunun ne tür bir hayvan olduğunu bulmak, yani “Görev Tanımı”.

Evet, faaliyetin bu bölümünü (yazılım geliştirme) düzenlemek için girişimlerin yapıldığı gerçekten GOST'ler ve standartlar var. Bir zamanlar, tüm bu GOST'lar ilgiliydi ve aktif olarak kullanılıyordu. şimdi var farklı görüşler Bu belgelerin alaka düzeyi ile ilgili olarak. Bazıları, GOST'lerin çok ileri görüşlü insanlar tarafından geliştirildiğini ve hala alakalı olduğunu iddia ediyor. Diğerleri umutsuzca modası geçmiş olduklarını söylüyor. Belki birileri şimdi gerçeğin ortada bir yerde olduğunu düşündü. Goethe'nin sözleriyle cevap verirdim: “İki karşıt görüş arasında gerçek yatar derler. Hiçbir durumda! Aralarında bir sorun var." Dolayısıyla bu görüşler arasında doğruluk payı yoktur. Çünkü GOST'ler modern gelişimin pratik sorunlarını ortaya çıkarmaz ve onları eleştirenler alternatifler (spesifik ve sistemik) sunmazlar.

GOST'un açıkça bir tanım bile vermediğini unutmayın, yalnızca şöyle diyor: “NGS için Görev Tanımı, otomatik bir sistemin oluşturulması (geliştirme veya modernizasyon - daha fazla oluşturma) için gereklilikleri ve prosedürü tanımlayan ana belgedir. NGS'nin geliştirilmesinin gerçekleştirildiği ve işletmeye alınması üzerine kabulünün gerçekleştirildiği belgedir."

Birisi hangi GOST'lardan bahsettiğimi merak ediyorsa, işte buradalar:

• GOST 2.114-95 Tasarım dokümantasyonu için birleşik sistem. Özellikler;
• GOST 19.201-78 Birleşik program dokümantasyon sistemi. Teknik görev. İçerik ve tasarım gereksinimleri;
• GOST 34.602-89 Bilgi Teknolojisi. Otomatik sistemler için standartlar seti. Otomatik bir sistemin oluşturulması için görev tanımı.

Wikipedia'da çok daha iyi bir tanım sunulmaktadır (sadece yazılım için değil, genel olarak TK hakkındaki gerçek): " teknik görev orijinal tasarım belgesidir teknik nesne. teknik görev geliştirilmekte olan nesnenin ana amacını, teknik ve taktik ve teknik özelliklerini, kalite göstergelerini ve teknik ve ekonomik gereklilikleri, dokümantasyon oluşturmanın gerekli aşamalarını (tasarım, teknolojik, yazılım vb.) ve bileşimini tamamlamak için talimatları şu şekilde belirler: yanı sıra özel gereksinimler. Yeni bir şeyin yaratılması için kaynak belge olarak bir görev, adı, içeriği, yürütme sırası vb. bakımından farklılık gösteren tüm faaliyet alanlarında mevcuttur (örneğin, inşaatta bir tasarım görevi, bir savaş görevi, Ev ödevi, için sözleşme edebi eser vesaire.)"

Ve tanımdan da anlaşılacağı gibi, Görev Tanımının ana amacı, bizim durumumuzda otomatik bir sistem için geliştirilmekte olan nesne için gereksinimleri formüle etmektir.

Ana olan, ama tek olan. Asıl şeyi üstlenmenin zamanı geldi: söz verildiği gibi her şeyi "raflara" koymak.

Gereksinimler hakkında bilmeniz gerekenler nelerdir? Tüm gereksinimlerin türe ve özelliklere göre bölünmesi gerektiği açıkça anlaşılmalıdır. Şimdi nasıl yapacağımızı öğreneceğiz. Gereksinimleri türe göre ayırmak için GOST bize yardımcı olacaktır. Orada sunulan gereksinim türlerinin listesi, hangi tür gereksinimlerin dikkate alınması gerektiğine dair iyi bir örnektir. Örneğin:

• işlevsellik gereksinimleri;
• Güvenlik ve erişim hakları için gereksinimler;
• Personel kalifikasyonu için gereklilikler;
• …. Vesaire. Onlar hakkında bahsedilen GOST'ta okuyabilirsiniz (ve aşağıda onları biraz daha ayrıntılı olarak ele alacağım).

Bence senin için açık anahtar faktör başarılı Görev Tanımları, işlevsellik için tam olarak iyi formüle edilmiş gereksinimlerdir. Bahsettiğim çalışmaların ve yöntemlerin çoğuna ayrılan şey bu gereksinimlerdir. İşlevsellik gereksinimleri, İş Tanımı'nın geliştirilmesindeki karmaşıklığın %90'ını oluşturur. Diğer her şey genellikle bu gereksinimlerin üzerine konulan "kamuflajdır". Gereksinimler zayıf bir şekilde formüle edilmişse, üzerlerine ne kadar güzel kamuflaj koyarsanız koyun, başarılı bir proje çalışmayacaktır. Evet, resmi olarak tüm gereksinimler karşılanacak (GOST J'ye göre), Görev Tanımı geliştirildi, onaylandı ve imzalandı ve bunun için para alındı. Ve ne? Ve sonra eğlence başlıyor: ne yapmalı? Bu Devlet Düzeni ile ilgili bir projeyse, o zaman sorun yok - öyle bir bütçe var ki hiçbir cebe sığmayacak, uygulama sürecinde (varsa) her şey netleşecek. Devlet Emirlerindeki projelerin bütçelerinin çoğu bu şekilde kesildi (“TK” yı ateşlediler, on milyonları birleştirdiler, ancak projeyi yapmaya başlamadılar. Tüm formaliteler karşılandı, suçlu yoktu, a evin yanında yeni araba.Güzellik!). Ama paranın sayıldığı ticari kuruluşlardan bahsediyoruz ve sonuç farklı. Bu nedenle, ana şeyle ilgilenelim, nasıl geliştirilir faydalı ve çalışan görev tanımı.

Gereksinim türleri hakkında söyledim, peki ya özellikler? Gereksinim türleri farklı olabilirse (projenin hedeflerine bağlı olarak), o zaman özelliklerle her şey daha basittir, bunlardan 3 tanesi vardır:

1. gereklilik olmalıdır anlaşılır;
2. gereklilik olmalıdır beton;
3. gereklilik olmalıdır test edildi;

Üstelik son özellik, önceki iki özellik olmadan imkansızdır, yani. bir çeşit "turnusol testi"dir. Bir gereksinimin sonucu test edilemiyorsa, o zaman ya net değildir ya da spesifik değildir. Bunu düşün. Beceri ve profesyonelliğin yattığı, gereksinimlerin bu üç özelliğine sahip olmaktır. Aslında her şey çok basit. Anladığında.

İş Tanımı'nın ne olduğu hakkındaki bu hikayeyi tamamlayıp ana konuya geçilebilir: gereksinimlerin nasıl formüle edileceği. Ama her şey o kadar hızlı değil. Son derece önemli bir nokta daha var:

• görev tanımı hangi dilde (anlamanın karmaşıklığı açısından) yazılmalıdır?
• İçinde çeşitli işlevlerin, algoritmaların, veri türlerinin ve diğer teknik şeylerin özellikleri açıklanmalı mı?
• Ve bu arada GOST'larda da bahsedilen teknik tasarım nedir ve Görev Tanımı ile nasıl bir ilişkisi vardır?

Bu soruların cevaplarında çok sinsi bir şey var. Bu nedenle, gereksinimlerin gerekli ayrıntılarının yeterliliği veya yokluğu, belgenin Müşteri ve Yükleniciler tarafından anlaşılabilirliği, fazlalık, sunum biçimi vb. Ve Görev Tanımı ile Teknik Tasarım arasındaki sınır nerede?

teknik görev Müşteri için anlaşılır (alışılmış, tanıdık) bir dilde formüle edilmiş gereksinimlere dayalı bir belgedir. Bu durumda, Müşterinin anlayabileceği endüstri terminolojisi kullanılabilir ve kullanılmalıdır. Teknik uygulamanın özelliklerine ilişkin herhangi bir bağlayıcılık olmamalıdır. Onlar. TK aşamasında prensip olarak bu gereksinimlerin hangi platformda uygulanacağı önemli değildir. İstisnalar olmasına rağmen. Mevcut bir yazılım ürününe dayalı bir sistemin uygulanmasından bahsediyorsak, böyle bir bağlama gerçekleşebilir, ancak yalnızca ekran formları, rapor formları vb. iş analisti. Ve kesinlikle bir programcı değil (bu rolleri birleştirmediği sürece bu olur). Onlar. bu kişi, Müşteri ile işinin dilinde konuşmalıdır.

teknik proje Görev Tanımında formüle edilen gereksinimlerin teknik olarak uygulanmasını amaçlayan bir belgedir. Sadece bu belge veri yapılarını, tetikleyicileri ve saklı yordamları, algoritmaları ve gerekli olacak diğer şeyleri açıklar. teknik uzmanlar . Müşterinin bunu araştırmasına hiç gerek yoktur (bu tür terimleri anlamayabilir). Teknik proje yapar Sistem mimarı(Burada bu rolün programcı ile birleşmesi oldukça normaldir). Daha kesin olmak gerekirse, bir mimar tarafından yönetilen bir grup AO uzmanı. Proje ne kadar büyük olursa, o kadar fazla Daha fazla insan Görev Tanımı üzerinde çalışıyor.

Pratikte elimizde ne var? Yönetmenin teknik terminoloji, veri türlerinin açıklamaları ve değerleri, veritabanı yapısı vb. İle dolu Görev Tanımı tarafından onaylanmak üzere getirildiğini izlemek komik. iddia etmek, satırlar arasında tanıdık kelimeler bulmaya çalışmak ve zincir iş gereksinimlerini kaybetmemek. Ne, tanıdık bir durum mu? Ve nasıl bitiyor? Kural olarak, bu tür bir Görev Tanımı onaylanır, daha sonra uygulanır ve vakaların% 80'inde, yapılan işin gerçeğine hiç karşılık gelmez, çünkü değiştirmeye karar verdikleri, yeniden yaptıkları, yanlış anladıkları, yanlış düşündükleri vb. birçok şey. ve benzeri. Ve sonra devir teslim serisi başlar. "Ama burada ihtiyacımız olan yol değil" ama "bizim için çalışmayacak", "çok karmaşık", "uygunsuz" vb. Aşina?! Bu yüzden biliyorum, tümsekleri zamanında doldurmam gerekiyordu.

Peki pratikte elimizde ne var? Ama pratikte elimizde bulanık sınırİş Tanımı ve Teknik Tasarım arasında. TK ve TP arasında çeşitli şekillerde yüzer. Ve bu kötü. Ve öyle çıkıyor çünkü kalkınma kültürü zayıfladı. Bu kısmen uzmanların yeterliliğinden, kısmen de bütçeleri ve son teslim tarihlerini azaltma arzusundan kaynaklanmaktadır (sonuçta, belgeleme çok zaman alır - bu bir gerçektir). Teknik Tasarımın ayrı bir belge olarak kullanımını etkileyen bir başka önemli faktör daha vardır: hızlı geliştirme araçlarının yanı sıra geliştirme metodolojilerinin hızlı gelişimi. Ama bu ayrı bir hikaye, aşağıda bununla ilgili birkaç söz söyleyeceğim.

Küçük ama önemli bir nokta daha. Bazen İş Tanımı, basit ve anlaşılır küçük bir gereksinim parçası olarak adlandırılır. Örneğin, bir nesne için aramayı bazı koşullara göre hassaslaştırmak, rapora bir sütun eklemek vb. Ancak büyük projelerde değil, küçük iyileştirmelerde kullanılır. Bunun yazılım ürününün bakımına daha yakın olduğunu söyleyebilirim. Bu durumda, Görev Tanımı, gerekliliğin uygulanması için özel bir teknik çözümü de tanımlayabilir. Örneğin, programcı için belirli bir prosedürü ve belirli bir değişikliği belirten “Algoritmada şu veya bu değişikliği yapmak için”. Bu, Görev Tanımı ile Teknik Projeler arasındaki sınırın tamamen silindiği durumdur, çünkü gerekmediği yerde evrakları şişirmenin ekonomik bir fizibilitesi yoktur ve faydalı bir belge oluşturulur. Ve bu doğru.

Gerçekten bir teknik şartnameye ihtiyacınız var mı? Mühendislik projesi ne olacak?

Aşırı ısınmış mıyım? Bu olmadan mümkün mü başvuru şartları? Düşünün belki (daha doğrusu oluyor) ve bu yaklaşımın birçok takipçisi var ve sayıları artıyor. Kural olarak, genç uzmanlar Scrum, Agile ve diğer hızlı gelişen teknolojiler hakkında kitaplar okuduktan sonra. Aslında bunlar harika teknolojiler ve çalışıyorlar, ancak kelimenin tam anlamıyla "teknik görevler yapmaya gerek yok" demiyorlar. “Minimum evrak işi” diyorlar, özellikle gereksiz olanlar, Müşteriye daha yakın, daha ayrıntılı ve daha hızlı sonuçlar. Ancak hiç kimse gereksinimlerin sabitlenmesini iptal etmedi ve orada açıkça belirtildi. Yukarıda bahsettiğim üç harika özelliğe göre gereksinimlerin belirlendiği yer burasıdır. Sadece bazı insanların bilinci öyle bir şekilde düzenlenmiştir ki, eğer bir şey basitleştirilebiliyorsa, onu tamamen yok olacak şekilde sadeleştirelim. Einstein'ın dediği gibi " Mümkün olduğu kadar basitleştirin, ancak bundan daha basit değil." . Altın sözler her şeyle gider. Bu yüzden teknik görev gerekli, aksi takdirde başarılı bir proje göremezsiniz. Başka bir soru, nasıl besteleneceği ve oraya nelerin dahil edileceğidir. Hızlı geliştirme metodolojileri ışığında, sadece gereksinimlere odaklanmanız gerekir ve tüm “kamuflaj” atılabilir. Temel olarak buna katılıyorum.

Teknik proje ne olacak? Bu belge çok kullanışlıdır ve alaka düzeyini kaybetmemiştir. Dahası, çoğu zaman onsuz yapmak imkansızdır. Özellikle dış kaynak geliştirme çalışmaları söz konusu olduğunda, yani. taşeronluk ilkesine göre. Bu yapılmazsa, aklınızdaki sistemin nasıl olması gerektiğine dair çok şey öğrenme riski vardır. Müşteri onu tanımalı mı? İstiyorsa neden olmasın ama ısrar etmeye ve bu belgeyi onaylamaya gerek yok, sadece işi kısıtlayacak ve engelleyecektir. En ince ayrıntısına kadar bir sistem tasarlamak neredeyse imkansızdır. Bu durumda Teknik Tasarımda sürekli değişiklik yapmanız gerekecek ki bu çok zaman alıyor. Ve eğer organizasyon ağır bir şekilde bürokratikleşmişse, o zaman genellikle tüm sinirleri orada bırakın. Yukarıda bahsettiğim modern hızlı geliştirme metodolojilerinde tartışılan tam da bu tür bir tasarım indirgemesidir. Bu arada, hepsi zaten yaklaşık 20 yaşında olan klasik XP (aşırı programlama) yaklaşımına dayanıyor. Bu nedenle, Müşterinin anlayabileceği yüksek kaliteli bir Görev Tanımı yapın ve Teknik Tasarımı sistem mimarı ile programcılar arasındaki ilişki için dahili bir belge olarak kullanın.

Teknik tasarımla ilgili ilginç bir detay: konu yönelimi ilkesine göre düzenlenmiş bazı geliştirme araçları (1C ve benzeri gibi), tasarımın (dokümantasyon süreci anlamına gelir) yalnızca tüm alt sistemler arasında etkileşimin gerekli olduğu gerçekten karmaşık alanlarda gerekli olduğunu öne sürer. En basit durumda, örneğin bir referans kitabı, bir belge oluşturmak için yalnızca doğru şekilde formüle edilmiş iş gereksinimleri yeterlidir. Bu, uzmanların eğitimi açısından bu platformun iş stratejisi ile kanıtlanmaktadır. Bir uzmanın sınav biletine bakarsanız ("programcı" değil, buna denir), o zaman orada yalnızca iş gereksinimleri olduğunu ve bunların bir programlama dilinde nasıl uygulanacağını göreceksiniz. bir uzman. Onlar. Görevin Teknik Tasarımın çözmek için tasarlandığı kısmı, uzmanın "kafasında" çözmesi gerekir (orta karmaşıklıktaki görevlerden bahsediyoruz) ve burada ve şimdi, yine belirli geliştirme ve tasarım standartlarını izleyerek 1C şirketi tarafından platformu için oluşturulmuştur. Böylece çalışmalarının sonucu aynı görünen iki uzmandan biri sınavı geçebilir, ikincisi geçemez çünkü. geliştirme standartlarını büyük ölçüde ihlal etti. Yani, uzmanların tipik görevleri sistem mimarlarını dahil etmeden kendi başlarına tasarlayabilecek niteliklere sahip olmaları gerektiği açıkça varsayılmaktadır. Ve bu yaklaşım işe yarıyor.

"İş Tanımı'na hangi gereklilikler dahil edilmelidir?" Sorusunu incelemeye devam edelim.

Bilgi sistemi için gereksinimlerin formüle edilmesi. Görev Tanımının Yapısı

Hemen açıklığa kavuşturalım: Bir bilgi sistemi için gereksinimlerin formülasyonu hakkında konuşacağız, yani. iş gereksinimlerinin geliştirilmesi, iş süreçlerinin resmileştirilmesi ve önceki tüm danışmanlık çalışmalarının tamamlanmış olduğu varsayılarak. Elbette bu aşamada bazı iyileştirmeler yapılabilir, ancak yalnızca iyileştirmeler yapılabilir. Otomasyon projesinin kendisi iş problemini çözmez - bunu aklınızda bulundurun. Bu bir aksiyomdur. Nedense bazı yöneticiler, programı satın alırlarsa kaotik bir işte düzenin geleceğine inanarak bunu çürütmeye çalışıyorlar. Ama sonuçta bir aksiyom, kanıt gerektirmeyen bir aksiyomdur.

Herhangi bir faaliyette olduğu gibi, gereksinimlerin formülasyonu aşamalara ayrılabilir (ve ayrılmalıdır). Her şeyin bir zamanı var. Bu zor bir entelektüel çalışmadır. Ve yetersiz dikkat ile tedavi edilirse sonuç uygun olacaktır. Uzman tahminlerine göre, Görev Tanımını geliştirmenin maliyeti %30-50 olabilir. ben de aynı fikirdeyim 50 belki de çok fazla olmasına rağmen. Ne de olsa, İş Tanımı geliştirilecek son belge değil. Sonuçta bir de teknik tasarım olmalı. Bu varyasyon, geliştirme sırasında proje ekipleri tarafından kullanılan farklı otomasyon platformları, yaklaşımları ve teknolojilerinden kaynaklanmaktadır. Örneğin C++ gibi klasik bir dilde geliştirmeden bahsediyorsak detaylı teknik tasarım olmazsa olmazdır. Sistemin 1C platformunda uygulanmasından bahsediyorsak, yukarıda gördüğümüz gibi tasarımla ilgili durum biraz farklıdır (ancak sıfırdan bir sistem geliştirirken klasik şemaya göre tasarlanmasına rağmen).

Gereksinimlerin formülasyonu ana kısım olmasına rağmen başvuru şartları, ve bazı durumlarda İş Tanımının tek bölümü haline gelir, bunun önemli bir belge olduğu gerçeğine dikkat etmeli ve buna göre düzenlenmelidir. Nereden başlamalı? Her şeyden önce, içerikle başlamanız gerekir. İçeriği oluşturun ve ardından yayınlamaya başlayın. Şahsen bunu yapıyorum: önce içeriğin ana hatlarını çiziyorum, hedefleri, tüm giriş bilgilerini tanımlıyorum ve sonra ana kısmı - gereksinimlerin formüle edilmesini - üstleniyorum. Neden tersi olmasın? Bilmiyorum, benim için daha uygun. Birincisi, bu, zamanın çok daha küçük bir kısmıdır (gereksinimlere kıyasla) ve ikincisi, tüm giriş bilgilerini açıklarken ana konuya geçersiniz. Peki kim severse. Zamanla, kendi İş Tanımı şablonunuzu geliştireceksiniz. Başlangıç ​​\u200b\u200bolarak, tam olarak GOST'ta açıklanan içeriği almanızı öneririm. İçerik için harika! Ardından, aşağıdaki üç özellik için önerileri unutmadan her bölümü alıp açıklamaya başlıyoruz: anlaşılabilirlik, özgüllük ve test edilebilirlik. Neden bunda bu kadar ısrar ediyorum? Bir sonraki bölümde bununla ilgili daha fazla bilgi. Ve şimdi, TK'nın GOST'ta önerilen noktalarından geçmek için çok incelik öneriyorum.

1. Genel bilgi;
2. sistemin yaratılmasının (geliştirilmesinin) amacı ve hedefleri;
3. otomasyon nesnelerinin özellikleri;
4. sistem gereksinimleri;
5. sistemin oluşturulmasına ilişkin çalışmanın bileşimi ve içeriği;
6. sistemin kontrolü ve kabulü için prosedür;
7. sistemi devreye almak için otomasyon nesnesini hazırlamak için işin bileşimi ve içeriği için gereklilikler;
8. dokümantasyon gereklilikleri;
9. geliştirme kaynakları.

Her biri ayrıca alt bölümlere ayrılmış toplam 9 bölüm. Bunları sırayla ele alalım. Kolaylık sağlamak için, her öğe için her şeyi bir tablo şeklinde sunacağım.

Bölüm 1. genel bilgiler.

GOST'a göre öneriler
sistemin tam adı ve sembolü;	Burada her şey açık: sistemin adının ne olacağını, kısa adını yazıyoruz
sözleşmenin konu şifresi veya şifresi (sayı);	Bu alakalı değil, ancak gerekirse belirtebilirsiniz.
sistemin geliştiricisi ve müşterisinin (kullanıcısının) işletmelerinin (derneklerinin) adı ve detayları;	projede kimin (hangi kuruluşların) çalışacağını belirtin. Ayrıca rollerini de belirtebilirsiniz.Bu bölümü tamamen silebilirsiniz (oldukça resmi).
sistemin oluşturulduğu, bu belgelerin kim tarafından ve ne zaman onaylandığı temelinde belgelerin bir listesi;	Yardımcı bilgi. Burada, gereksinimlerin belirli bir bölümünü tanımak için size sağlanan düzenleyici ve referans belgeleri belirtmelisiniz.
sistemin oluşturulmasına ilişkin çalışmaların başlaması ve tamamlanması için planlanan tarihler;	Zamanlama dilekleri. Bazen bunun hakkında Görev Tanımında yazarlar, ancak daha çok bu tür şeyler iş sözleşmelerinde açıklanır.
işin finansmanı için kaynaklar ve prosedür hakkında bilgi;	Benzer şekilde, zamanlama ile ilgili önceki paragrafta olduğu gibi. Devlet emirleriyle daha alakalı (devlet çalışanları için)
sistemin (parçalarının) oluşturulması, bireysel araçların (donanım, yazılım, bilgi) ve yazılım ve donanım (yazılım ve metodolojik) komplekslerinin üretimi ve ayarlanması ile ilgili çalışmaların sonuçlarını resmileştirme ve müşteriye sunma prosedürü sistem.	Bu paragrafa gerek görmüyorum, tk. dokümantasyon gereksinimleri ayrı ayrı yapılır ve bunun yanı sıra, sistemin tamamen ayrı bir "Kontrol ve kabul prosedürü" bölümü vardır.

Bölüm 2. sistemin yaratılmasının (geliştirilmesinin) amacı ve hedefleri.

GOST'a göre öneriler	Pratikte bununla ne yapmalı
sistemin amacı	Bir yandan, randevu basittir. Ama spesifik olmak istiyorum. "X şirketinde depo muhasebesinin yüksek kaliteli otomasyonu" gibi bir şey yazarsanız, gereksinimlerin iyi ifade edilmesinden bağımsız olarak sonucu, tamamlandığında uzun süre tartışabilirsiniz. Çünkü Müşteri her zaman kalite ile başka bir şeyi kastettiğini söyleyebilir. Genelde sinirler birbirini çok bozabilir ama neden? Hemen şöyle bir şey yazmak daha iyidir: "Sistem, bu Görev Tanımında belirtilen gerekliliklere uygun olarak X şirketindeki depo kayıtlarını tutmak için tasarlanmıştır."
Bir sistem oluşturmanın amaçları	Goller kesinlikle önemli bir bölüm. Açarsak, bu hedefleri formüle edebilmeliyiz. Hedeflerin formülasyonunda zorluk yaşıyorsanız, bu bölümü tamamen hariç tutmak daha iyidir. Başarısız bir hedef örneği: "Yöneticinin evrak işlerini hızlı yapmasını sağlayın." Hızlı nedir? Bu daha sonra sonsuza kadar kanıtlanabilir. Önemliyse, yeniden formüle etmek daha iyidir bu hedefşöyle: "Satış müdürü, 10 dakikada 100 satırlık" Malların Satışı "belgesini düzenleyebilmelidir." Böyle bir hedef, örneğin yönetici şu anda buna yaklaşık bir saat harcıyorsa görünebilir ki bu şirket için çok fazla ve onlar için önemli. Bu formülasyonda hedef, gereksinimlerle zaten kesişiyor ki bu oldukça doğal çünkü. hedefler ağacını genişletirken (yani onları daha küçük ilgili hedeflere bölerken), gereksinimlere zaten yaklaşmış oluruz. Bu nedenle, kendinizi kaptırmamalısınız.

Genel olarak, hedefleri belirleme, bunları formüle etme, bir hedef ağacı oluşturma yeteneği tamamen ayrı bir konudur. Ana şeyi hatırlayın: Nasıl yapılacağını biliyorsanız - yazın, emin değilseniz - hiç yazmayın. Hedef belirlemezseniz ne olur? Gereksinimlere göre çalışacaksınız, bu genellikle uygulanır.

Bölüm 3. Otomasyon nesnelerinin özellikleri.

Bölüm 4 Sistem Gereksinimleri

GOST, bu tür gereksinimlerin listesini deşifre eder:

• sistemin yapısı ve işleyişi için gereksinimler;
• sistem personelinin sayısı ve nitelikleri ile çalışma şekli için gereklilikler;
• hedef göstergeleri;
• güvenilirlik gereksinimleri;
• güvenlik gereksinimleri;
• ergonomi ve teknik estetik gereksinimleri;
• mobil AS için taşınabilirlik gereksinimleri;
• sistem bileşenlerinin çalıştırılması, bakımı, onarımı ve depolanması için gereksinimler;
• bilgilerin yetkisiz erişimden korunması için gereklilikler;
• kaza durumunda bilgilerin güvenliği için gereklilikler;
• dış etkilerin etkisinden korunma gereksinimleri;
• patent saflığı için gereklilikler;
• standardizasyon ve birleştirme gereksinimleri;

Ana bölüm, elbette, özel gereksinimler (işlevsel) içeren bölüm olmasına rağmen, bu bölüm aynı zamanda büyük önem(ve çoğu durumda vardır). Neler önemli ve yararlı olabilir:

• Kalite gereksinimleri. Geliştirilmekte olan sistemin uzmanların yeniden eğitilmesini gerektirmesi mümkündür. Kullanıcılar gibi olabilir gelecekteki sistem ve onu desteklemek için ihtiyaç duyulacak BT uzmanları. Bu konuya yeterince dikkat edilmemesi sıklıkla sorunlara dönüşür. Mevcut personelin nitelikleri açıkça yetersiz ise, eğitim organizasyonu, eğitim programı, dönemler vb. için gereklilikleri belirlemek daha iyidir.
• Bilgilerin yetkisiz erişime karşı korunması için gereksinimler. Burada yorum yok. Bu tam olarak verilere erişim kontrolü için gereksinimlerdir. Bu tür gereksinimler planlanırsa, işlevsel gereksinimlerle aynı kurallara göre (anlaşılabilirlik, özgüllük, test edilebilirlik) mümkün olduğunca ayrıntılı olarak ayrı ayrı yazılması gerekir. Bu nedenle, bu gereksinimler, işlevsel gereksinimler bölümüne dahil edilebilir.
• standardizasyon için gereksinimler. Projeye uygulanabilir herhangi bir geliştirme standardı varsa, bunlar gereksinimler arasına dahil edilebilir. Kural olarak, bu tür gereksinimler Müşterinin BT hizmeti tarafından başlatılır. Örneğin, 1C şirketinin program kodu tasarımı, arayüz tasarımı vb.
• Sistemin yapısı ve işleyişi için gereksinimler. Burada sistemlerin birbirleri ile entegrasyonu için gereksinimler açıklanabilir, genel mimarinin bir açıklaması sunulur. Daha sık olarak, entegrasyon gereklilikleri genel olarak ayrı bir bölümde veya hatta ayrı bir Görev Tanımında belirtilir, çünkü bu gereksinimler oldukça karmaşık olabilir.

Diğer tüm gereksinimler daha az önemlidir ve dışarıda bırakılabilir. Kanımca, yalnızca belgeleri daha ağır hale getiriyorlar ve çok az pratik kullanımları var. Ve ergonomi gereksinimlerini genel gereksinimler şeklinde tanımlamak çok zordur, bunları işlevsel olanlara aktarmak daha iyidir. Örneğin, "Bir ürünün fiyatı hakkında sadece bir tuşa basarak bilgi alın" şartı formüle edilebilir. Kanımca, bu, ergonomi ile ilgili olmasına rağmen, yine de belirli işlevsel gereksinimlere daha yakındır.Sistem tarafından gerçekleştirilen işlevler (görevler) için gereksinimler İşte başarıyı belirleyecek en önemli ve kilit nokta burasıdır. Her şey mükemmel bir şekilde yapılsa ve bu bölüm "3" de olsa bile, o zaman proje için sonuç en iyi ihtimalle "3" olur, hatta proje başarısız olur. Bunlar, e-posta listesinin 5. sayısında yer alacak olan ikinci yazıda daha ayrıntılı olarak ele alacağımız konular. Bahsettiğim “gereksinimlerin üç özelliği kuralı” işte bu noktada geçerlidir.Güvenlik türleri için gereksinimler

GOST aşağıdaki türleri ayırt eder:

• Matematiksel
• bilgilendirme
• dilsel
• Yazılım
• Teknik
• metrolojik
• organizasyonel
• metodik
• ve diğerleri…

İlk bakışta, bu gereksinimler önemli değil gibi görünebilir. Bu çoğu proje için geçerlidir. Ama her zaman değil. Bu gereksinimler ne zaman açıklanmalıdır:

• Geliştirmenin hangi dilde (veya platformda) olacağına dair herhangi bir karar verilmedi;
• Sistem, çok dilli bir arayüzün gereksinimlerine tabidir (örneğin, Rusça / İngilizce)
• Sistemin işlemesi için ayrı bir birim oluşturulmalı veya yeni çalışanlar işe alınmalı;
• Sistemin işleyebilmesi için Müşteri'nin çalışma yöntemlerinde değişikliklere uğraması ve bu değişikliklerin belirlenip planlanması gerekir;
• Bazı ekipmanlarla entegrasyon varsayılır ve gereklilikler getirilir (örneğin, sertifika, uyumluluk vb.)
• Başka durumlar da mümkündür, hepsi projenin özel hedeflerine bağlıdır.

Bölüm 5. Sistemin oluşturulmasına ilişkin çalışmanın bileşimi ve içeriği

Bölüm 6. Sistemin kontrolü ve kabulü için prosedür

İşin aşamalara göre kabulü için genel gereklilikler (katılan işletme ve kuruluşların listesi, yer ve zamanlama), kabul belgelerini kabul etme ve onaylama prosedürü; İş teslimi ve sistemi kontrol etme prosedürünün sorumluluğunu almanızı şiddetle tavsiye ederim. Test edilebilir gereksinimler bunun içindir, ancak sistemin teslimi sırasında test edilebilir gereksinimlerin varlığı bile, işin kabulü ve devri için prosedür açıkça belirtilmemişse yeterli olmayabilir. Örneğin, yaygın bir tuzak: sistem tamamlandı, tamamen işlevsel, ancak Müşteri nedense içinde çalışmaya hazır değil. Bu nedenler herhangi biri olabilir: bir kez, hedefler değişti, birisi ayrıldı, vb. Ve diyor ki: "Henüz yeni sistemde çalışmadığımız için çalıştığından emin olamayız." Bu nedenle, işin aşamalarını, bu aşamaların sonuçlarını kontrol etmenin yollarını doğru bir şekilde tanımlamayı öğrenin. Ayrıca, bu tür yöntemler en başından itibaren Müşteri için açık olmalıdır. Görev Tanımı düzeyinde sabitlenmişlerse, gerekirse onlarla her zaman iletişime geçebilir ve işi aktarımla tamamlayabilirsiniz.

Bölüm 7. Sistemi faaliyete geçirmek için otomasyon nesnesini hazırlamak için işin bileşimi ve içeriği için gereklilikler

Şirket tarafından kabul edilen (veya planlanan) bilgilerin girilmesi için başka kurallar olabilir. Örneğin, sözleşme ile ilgili bilgiler önceden keyfi bir biçimde metin satırı olarak girilirken, şimdi sayı ayrı, tarih ayrı isteniyor vs. Bu tür birçok durum olabilir. Bazıları personelin direnci ile algılanabilir, bu nedenle tüm bu tür durumları veri giriş sırası için gereksinimler düzeyinde kaydetmek daha iyidir Otomasyon nesnesinde yapılması gereken değişiklikler

Oluşturulan sistemin TOR'da yer alan gerekliliklere uygunluğunun garanti edildiği otomasyon nesnesinin işleyişi için koşulların oluşturulması Gerekli olabilecek herhangi bir değişiklik. Örneğin şirketin elinde yok. yerel ağ, sistemin çalışmadığı eski bir bilgisayar filosu.

Belki bazı gerekli bilgiler kağıt üzerinde işlendi ve şimdi sisteme girilmesi gerekiyor. Bu yapılmazsa, bazı modüller çalışmayacaktır, vb.

Belki bir şey basitleştirildi, ancak şimdi daha ayrıntılı olarak dikkate alınması gerekiyor, bu nedenle birisinin belirli kurallara göre bilgi toplaması gerekiyor.

Bu liste uzun olabilir, projenizin özel durumuna bakın Sistemin çalışması için gerekli departmanların ve hizmetlerin oluşturulması;

Personel alımı ve personel eğitimi için son tarihler ve prosedürler Bunu daha önce tartışmıştık. Belki de sistem daha önce olmayan yeni bir yapı veya faaliyet türü için geliştirilmektedir. Uygun personel yoksa ve hatta eğitimli değilse, sistem ne kadar yetkin inşa edilmezse kurulmaz.

Bölüm 8 Dokümantasyon Gereksinimleri

Kullanıcı kılavuzlarının nasıl sunulacağını düşünün.

Müşteri kurumsal standartları kabul etmiş olabilir, bu nedenle onlarla iletişime geçmeniz gerekir.

Dokümantasyon gerekliliklerini göz ardı etmek, projelerde genellikle en beklenmedik sonuçlara yol açar. Örneğin, her şey yapılır ve her şey çalışır. Kullanıcılar ayrıca nasıl çalışacaklarını da bilirler. Belgeler üzerinde hiç anlaşamadık ve konuşmadık. Ve birden iş teslim edildiğinde Müşteri'nin projeye bile katılmayan ancak iş kabulüne katılan üst düzey yöneticilerinden biri size soruyor: "Kullanım kılavuzları nerede?" Ve sizi kullanım kılavuzlarının mevcudiyeti konusunda anlaşmaya gerek olmadığına ikna etmeye başlar, iddiaya göre bu "tek başına" ima ediliyor. Ve hepsi bu, işinizi almak istemiyor. Kimin pahasına kılavuzlar geliştireceksiniz? Birçok takım bu kancaya çoktan aşık oldu.

Bölüm 9 Geliştirme Kaynakları

Bu nedenle, sadece kilit kişilerin gereksinimleri olan anket raporuna atıfta bulunmak daha iyidir.

Ve böylece, Görev Tanımında yer alabilecek tüm bölümleri değerlendirdik. "Yapabilir", "Zorunluluk" değil, çünkü bir sonuca ulaşmak için herhangi bir belgenin geliştirilmesi gerekir. Bu nedenle, bazı ayrı bölümlerin sizi sonuca yaklaştırmayacağı açıksa, o zaman ona ihtiyacınız yoktur ve üzerinde zaman kaybetmenize gerek yoktur.

Ancak asıl şey olmadan: işlevsel gereksinimler, yetkin bir şekilde tek bir Görev Tanımı tamamlanmadı. Uygulamada bu tür Görev Tanımlarıyla karşılaşıldığını ve nasıl olduğunu belirtmek isterim! Tüm bölümlerde suları sulandırabilecek, genel gereklilikleri genel hatlarıyla anlatabilecek rakamlar var ve belge çok ağır çıkıyor ve içinde pek çok zekice kelime var ve Müşteri bile beğenebilir. (yani onaylayacaktır). Ancak üzerinde çalışmak mümkün olmayabilir, yani. bunun için çok az pratik kullanım var. Çoğu durumda, bu tür belgeler, özellikle Görev Tanımı için çok para almanız gerektiğinde doğar ve bunu hızlı bir şekilde ve ayrıntılara dalmadan yapmanız gerekir. Ve özellikle işlerin daha ileri gitmeyeceği biliniyorsa veya bunu tamamen farklı insanlar yapacaksa. Genel olarak, sadece bütçenin, özellikle de devletin gelişimi için.

İkinci yazımızda sadece 4. bölüm olan “Sistem Gereksinimleri”nden bahsedeceğiz ve özellikle netlik, özgüllük ve test edilebilirlik nedenleriyle gereksinimleri formüle edeceğiz.

Gereksinimler neden açık, spesifik ve test edilebilir olmalıdır?

Çünkü uygulama gösteriyor ki: başlangıçta, uzmanlar tarafından geliştirilen teknik şartnamelerin çoğu ya talep edilmiyor (gerçeğe uymuyor) ya da bunları uygulaması gereken kişi için bir sorun haline geliyor, çünkü Müşteri, spesifik olmayan şartları ve gereksinimleri manipüle etmeye başlar. Hangi ifadelerle karşılaştığımdan, bunun neye yol açtığından birkaç örnek vereceğim ve ardından bu tür sorunlardan nasıl kaçınılacağına dair tavsiyeler vermeye çalışacağım.

Bu test edilebilir bir gereklilik mi? Basit bir şey gibi görünüyor, ancak ayrıntı yoksa nasıl kontrol edilir?

Nasıl yeniden formüle edilebilir: "Belgede belirtilen maliyet tutarı, bu belgede belirtilen tüm mallara, bu malların maliyeti ile orantılı olarak dağıtılmalıdır." Açık ve spesifikti. Nasıl kontrol edileceği de zor değil.

Ergonomi Programın kullanıcı dostu bir arayüzü olmalı, dürüst olmak gerekirse, bu ifadeye bir kez abone olmak zorunda kaldım - o zaman sayılacak bir sorun olmadı. Tabii ki, bu tür formülasyonlar olmamalıdır. Bu gereksinimi doğrulamak için hiçbir ayrıntı veya yetenek yoktur. Tabii ki anlaşılabilir olmasına rağmen (öznel olarak). Burada herhangi bir şekilde yeniden formüle etmek imkansızdır, Müşteri bu konuda ısrar ettiği için "uygunluğun" her bir unsurunu ayrıntılı olarak açıklamak gerekir. Örneğin:

• Belgeye hem “Ekle” butonu tıklanarak hem de “insert” tuşlarına basılarak veya kullanıcı tarafından ismin bir kısmı girilerek satırlar eklenmelidir;
• Bir mal listesini görüntülerken isim, barkod ve makaleye göre arama yapmak mümkün olmalıdır;
• vesaire.

Erişim haklarının farklılaştırılması Kârla ilgili verilere erişim yalnızca mali direktör tarafından sağlanmalı Anlaşıldı mı? Neredeyse. Doğru, kar farklı, açıklığa kavuşturmak gerekiyor, özellikle? Tabii ki değil. Uygulamada nasıl görünüyor? Brüt kârdan bahsediyorsak, satın alma maliyetiyle ilgili verilere erişimi kısıtlamak gerekir, çünkü. Aksi takdirde, satış verilerinin maliyeti geniş bir insan kitlesi tarafından bilindiğinden brüt kârı hesaplamak kolaydır. Erişim hakları söz konusu olduğunda, çok dikkatli olmanız gerekir. Ve eğer satış yöneticileri brüt karla motive oluyorsa, bu gereksinimler de birbiriyle çelişir çünkü. yöneticiler bunu asla doğrulayamaz. Halihazırda böyle bir gerekliliği dahil edersek, verilerin hangi bölümünün belirli kişi kategorileri tarafından kullanılabilir olması gerektiğini belirtmek için belirli raporları ve sistem nesnelerini belirtmemiz gerekir. Ve bu tür her durumu ayrı ayrı ele alın Verimlilik Satış raporu 1 dakika içinde oluşturulmalı Evet, anlıyorum. Ve hatta belirli bir zaman sınırı var: 1 dakika. Ancak bu durumda ne tür bir detaylandırma yapılması gerektiği bilinmemektedir: her ürün, ürün grubu, müşteri veya başka bir şey için, seçimdeki öğe sayısı 5000 satırı geçmemek koşuluyla 1 dakikadan fazla.

Umarım fikir açıktır. Spesifik sorularınız varsa yazın, yardımcı olmaya çalışırım.

için başvuru şartları daha fazla ayrıntı vardı, birçok öneri var. Referans şartlarında kullanılması önerilmeyen kelimelerin bir listesi bile var. K. Vigers, “Yazılım Gereksinimlerinin Geliştirilmesi” adlı kitabında bunu ilginç bir şekilde yazıyor. İşte bence en ilginç ve basit öneriler:

• Birçok eş anlamlısı olan sözcükleri kullanmayın. Gerekirse, Görev Tanımı'nın Terimler ve Tanımlar bölümünde terimin net bir tanımını vermek daha iyidir.
• Uzun cümleler kullanmamaya çalışmalısınız;
• Bir gereklilik size çok genel görünüyorsa, daha küçük ama özel gerekliliklere göre detaylandırılmalıdır;
• Daha fazla diyagram, grafik, tablo, çizim kullanın - bu şekilde bilgi çok daha kolay algılanır;
• Şu kelimelerden kaçınılmalıdır: “etkili”, “yeterli”, “basit”, “anlaşılır”, “hızlı”, “esnek”, “geliştirilmiş”, “optimal”, “şeffaf”, “sürdürülebilir”, “yeterli” , "arkadaş canlısı", "kolay" vb. Listeye devam edilebilir, ancak bence fikir açık (bunu kendiniz devam ettirmeye çalışın).

Yukarıda yazılanların hepsi önemli bilgilerdir, ancak en önemlisi değildir. Hatırlarsanız yazının başında buna "kamuflaj" adını vermiştim çünkü. Bir belge üzerinde çalışmanın zamanının ve karmaşıklığının en az %90'ını hesaba katacak en önemli şey, gereksinimlerin tanımlanması ve formüle edilmesidir. Ve gereksinimler hakkındaki bilgiler yine de toplanabilmeli, yapılandırılabilmeli ve formüle edilebilmelidir. Bu, bu arada, işletme anketi ile iş süreçlerinin müteakip açıklaması arasında pek çok ortak noktaya sahiptir. Ancak önemli farklılıklar da var. Bu temel farklılıklardan biri, geleceğin sisteminin bir prototipinin veya diğer adıyla “bilgi sistemi modelleri” inşa etme aşamasının varlığıdır.

Bir sonraki makalede, yalnızca gereksinimleri belirleme yöntemlerinden bahsedeceğiz ve ayrıca bir bilgi sistemi için gereksinimleri toplama işi ile iş süreçlerini tanımlamak için bilgi toplama işi arasındaki ortak noktaları ele alacağız.

Muhasebe sistemi için gereksinimleri ve iş süreçlerini açıklamak için bilgileri toplarken yapılan iş türleri. Bölüm 2

Bu bölümde gereksinimlerin toplanması ile ilgili çalışma aşamasının nasıl organize edileceğinden, nelerden oluşması gerektiğinden ve hangi araçların kullanılabileceğinden bahsedeceğiz. Bu çalışmaların aşamalar itibariyle iş süreçlerini anlatmak adına bir işletme anketine çok benzediğini tekrar ediyorum.

Hayatta her zamanki gibi:

Çoğu projede nasıl çalışır?
	bu nasıl oluyor
	Sevinmek için bir neden olduğu açık, özellikle proje büyükse, bunda yanlış bir şey yok! Asıl mesele çok uzun süre sevinmemek, asıl işin başlamasını geciktirmek, bundan sonra zaman farklı ilerleyecek.
	Genellikle bu süreç, yönetimle, ardından departman başkanlarıyla yapılan birkaç toplantıyla sınırlıdır. Müşteriden gelen bazı "dürtüler" sabitlendikten sonra, bunlar genel formülasyonlar şeklinde sabitlenir. Bazen mevcut belgeler buna eklenir (birileri bir kez inceleme yapmaya çalıştı, mevcut mevzuata göre belgeler, kullanılan rapor biçimleri) Şaşırtıcı bir şekilde, bundan sonra otomasyon sistemlerini uygulayanların çoğu sevinçle haykırıyor: “evet, sistemimiz geldi. hepsi bu! Pekala, küçük bir ince ayar ve her şey işe yarayacak. Son kullanıcılarla işlerin nasıl yürümesi gerektiğini (veya belirli bir sürecin nasıl gerçekleştirildiğini) tartışmanın gerekli olup olmadığı sorulduğunda, cevap genellikle hayırdır. Görüş, liderin astları için her şeyi bildiği ifade edilir. Ama nafile… Bunun arkasında pek çok tuzak ve engel vardır ve iş teslimi, engelli parkur boyunca bir maratona dönüşebilir. Bildiğiniz gibi düz bir yolda maraton koşmak adettendir ve engellerle koşmak ancak kısa mesafelerde mümkündür (koşmayabilirsiniz).
İş sonuçlarının belgelenmesi	Bundan sonra, çalışmanın amaçlarına bağlı olarak sonuçların belgelenmesi başlar: İş Tanımı geliştirmek gerekirse, danışman alınan bilgileri hazırlanan belge şablonuna göre güzel görünecek şekilde yaymaya başlar ve ana gereksinimler sabittir (yönetimden dile getirilenler, aksi halde onaylamayabilirler). Uygulamada böyle bir Görev Tanımının özellikle kullanılmadığını ve her şeyin "hareket halindeyken" çözülmesi gerektiğini fark ederek, Görev Tanımının ana hedefini koordinasyon ve onay için minimum süre olarak belirler. Ve mümkünse, gelecekteki çalışmanın maliyetinin kaba bir tahmini için bilgi (bu arada, bu da önemlidir). İş süreçlerini anlatmak isterseniz. İşin garibi, ancak çoğu zaman önceki tüm eylemler, Görev Tanımının geliştirilmesi durumunda olduğu gibi aynı görünüyor. Tek fark belgelerdedir. Burada seçenekler mümkündür: danışmanlar süreci gelişigüzel kelimelerle tanımlar veya iş süreçlerini (notasyonlar) açıklamak için herhangi bir kural kullanır. İlk durumda, böyle bir belgenin şaşırtıcı bir şekilde Görev Tanımına benzer olduğu ortaya çıkıyor. Değiştirirseniz bile olur Giriş sayfası, herhangi bir fark görmezsiniz. açıklama kurallarına resmi bağlılık Ne yazık ki, her iki seçenek de en en iyi pratik, Çünkü daha çok bir formalitedir ve pek bir fayda sağlamazlar.

Neden yukarıda anlatıldığı gibi bir uygulama var? itiraf ediyorum bilmiyorum. Kimse sormuyor, kimse bilmiyor. Aynı zamanda durum çok hızlı değişmiyor, bu konu sürekli tartışılmasına, deneyim alışverişinde bulunulmasına, kitaplar yazılmasına rağmen ... Bana öyle geliyor ki sebeplerden biri Düşük kalite ilgili eğitim. Pek çok uzmanın tamamen başka işletmelerden gelmesi ve pratikte her şeyi kavraması da etkilenebilir, yani. deneyimleri kendilerini içinde buldukları çevre tarafından şekillenir. Üniversitelerin tavrı ve gerçeğe daha yakın olma arzularının olmaması da bilinen bir gerçek ama bazen konumları beni şaşırtıyor. Örneğin, yetenekli bir uzman olan bir yüksek lisans öğrencisinin 1C platformunda (iyi bir endüstri gelişimi) bir tez yazmak istediğinde, ancak bölümde kendisine konu ne olursa olsun bunun imkansız olacağı söylendiğinde bir durumum vardı. "mükemmel" bir nota güvenmek, çünkü 1C ciddi bir sistem değil. Buradaki mesele, böyle bir görüşün ciddiyeti ve nesnelliği değil, klasik bir programlama dilindeki ilkel bir görevin hemen "mükemmel" bir derecelendirmeye layık görülmesidir.

Yukarıda tartışılan sürece daha sistematik bir yaklaşım vermeye çalışalım. O zaman nasıl görünebilir?

Gördüğünüz gibi süreç bir soru ile bitiyor çünkü bu konuda, iş henüz bitmedi ve sonra en zor ve en pratik olan başlayacak - elde edilen sonucun uygulanabilirliğini tam olarak ne belirleyecek? gerçek hayat. Bir önceki çalışmanın kaderini belirleyecek olan tam olarak budur: ya dolaba (bir rafa ya da başka bir yere) gidecek ya da değerli bir bilgi kaynağı olacaktır. Ve gelecekteki projeler için bir model haline gelirse daha da iyi.

Diyagramdaki son adıma kadar (sorunun nerede olduğu) özellikle not etmek istiyorum. Genel prensip Gelecekte yapılması planlananlar, iş süreçlerinin açıklanması veya otomatikleştirilmiş bir sistemin uygulanması ne olursa olsun, şirketin faaliyetleri hakkında bilgi toplamak aynı görünüyor. Evet, adımların sırası aynıdır, ancak bazılarında kullanılan araçlar farklılık gösterebilir. Bireysel aşamaların yöntemlerini ve araçlarını incelerken bu anı kesinlikle dikkate alacağız. Bunu ayrı makalelerde ayrıntılı olarak yapacağız, ancak şimdi yalnızca en önemlilerini ele alacağız. Diğer adımlar farklılık gösterecek ve projeden neyin gerekli olduğuna göre belirlenecektir: iş süreçlerini tanımlayın veya bir muhasebe sistemi uygulayın.

Şirketin faaliyetleri hakkında bilgi toplama yaklaşımını nasıl yeniden düzenleyebileceğinizi görelim.

Daha yetkin bir iş organizasyonu ile bu nasıl olabilir?
	bu nasıl oluyor
Karar verildi, proje olacak!	İlk seçenekle ilgili burada hiçbir şey değişmez, kimse duyguları iptal etmedi
Liderlerle bir toplantı yaptık, sonuca ilişkin vizyonları hakkında bilgi topladık.	Bu adım da kalır ve büyük önem taşır. Ancak yöneticiler ve mal sahipleri ile ilk görüşmenin (veya birkaç toplantının) asıl amacı tanışmadır. Her şeyden önce insanlarla ve şirketle tanışma. Bu tür genel toplantılarda formüle edilen hedefler ve dilekler, fantastik olanlar da dahil olmak üzere çok farklı olabilir. Elbette hepsi duyulacak, ancak bunların uygulanacağı gerçeği değil. Şirketin işine daha derin bir dalma ile, diğer hedefler ortaya çıkacak ve öncekiler reddedilecek. Demek istediğim, ön toplantılardan net hedefler formüle etmek imkansızdır, tüm bunlar dikkatli bir çalışma gerektirecektir, bu tür toplantılarda, sahiplerden ve üst düzey yetkililerden gelen tüm mesajları ana hatlarıyla belirtmek gerekir, böylece daha sonra onlara dönebilirsiniz. ve yeterli bilgi toplandığında tartışın. Görünüşte basit bir gereksinim bile gerçekleştirilemez veya çok zahmetli olabilir.
Müşteri ve Yükleniciden oluşan bir çalışma grubunun oluşturulması, rol dağılımı	Hem Müşteri hem de Yüklenici adına projede kimin çalışacağına karar vermek gerekir. Bu aşamanın görünürdeki basitliğine rağmen, çok önemli bir rolü vardır. Kimin neyden sorumlu olduğunu açıkça belirlemezseniz, işin uygulanması sırasında kafa karışıklığı yaşama riskiniz vardır. Kendi açınızdan, ekibinizdeki rolleri her zaman belirtebiliyorsanız, Müşterinin bununla ilgili sorunları olabilir. Neye dikkat etmelisiniz: Müşterinin çalışma grubu, gelecekte sonucun kabul edilmesini en azından bir şekilde etkileyecek kişileri mutlaka içermelidir. İş teslim edildiğinde, Müşteri'nin hedeflerin oluşturulması ve gereksinimlerin belirlenmesi çalışmalarına katılmayan çalışanlarının katılacağı varsayılırsa, o zaman sorunlar garanti edilir. Öyle saçma bir durum bile mümkündür ki her şeyin gerektiği gibi yapılmadığı ortaya çıkar.Uygulamamda böyle bir durumla birden fazla kez karşılaştım.Bu nedenle, kimsenin dışında kimsenin olmadığını şart koşar ve belgelerseniz kendinizi koruyabilirsiniz. Müşteri'nin çalışma grubu, işlerin kabulü ve tesliminde görev alabilir. Ve en iyisi, bunu sözleşme koşullarında (sözleşmede veya proje Şartında) belirtmek. Böyle bir durum olduğunu hatırlıyorum: büyük bir projede, kurucu sürece katılmaya karar verdi (nedenini bilmiyorum, görmek sıkıcı hale geldi) ve müşteriler için fatura oluşturma konusunun tartışıldığı çalışma toplantılarından birine katıldı. tartışıldı. Satış müdürünün faturayı müşteriye kestiğini öğrenince şaşırdı. Ona göre, muhasebeci bir fatura düzenlemeli ve başka bir şey düzenlememelidir. Ama aslında, muhasebecinin neyin tehlikede olduğu hakkında hiçbir fikri yoktu ve yönetici, her hesap için muhasebeciye koşarsa nasıl böyle çalışacağını hayal edemiyordu. Sonuç olarak çok zaman kaybettik ama hiçbir şey değişmedi, hesap yine de yönetici tarafından faturalandırıldı. Ve kurucu fikrinde kaldı ama artık sürece müdahale etmedi. Aynı aşamada, katılımcıların rollerini, iletişim prosedürünü, raporlama kurallarını ve kompozisyonunu ve ayrıca Şart'ta yazılması gereken diğer her şeyi belirleyen Proje Tüzüğü'nün geliştirilmesi tavsiye edilir. Proje Şartının geliştirilmesi yine ayrı bir konudur.
Proje ekibini çalışma yöntemleri ve araçları konusunda eğitmek, çalışma kuralları, dokümantasyon türleri ve bileşimi üzerinde anlaşmak	İlk olarak, Şart'ta yazılan her şeyi, pratikte nasıl uygulanacağını proje ekibine açıklamak gerekir. İkinci olarak, Müşterinin proje ekibinin sonraki tüm aşamalarda kullanacağınız çalışma yöntemleri konusunda eğitilmesi gerekir. Örnekleri dikkate almak için kullanılacak belge formatlarını tartışmak mantıklıdır. Modelleri veya iş süreçlerini tanımlamaya yönelik herhangi bir kural uygulanacaksa, anlaşılabilmesi için bu kuralların da tartışılması gerekir.
Anket	Anket aşaması nispeten izin verir hızlı yolşirket hakkında oldukça güvenilir bir bilgi parçası elde edin. Bu tür bilgilerin kalitesi üç faktör tarafından belirlenecektir: Her şeyden önce, müşterinin proje ekibini nasıl eğittiğiniz. Anket sürecinin nasıl gerçekleştiğini açıkça anlamalı ve tüm katılımcılara bilgi aktarabilmelidirler. Soru formunun kendisi. Anketler anlaşılır olmalıdır. Anketleri doldurmak için bir talimat olması arzu edilir. Doldurma örneği varsa daha da iyi. Katılımcı listesi. Katılımcıların doğru kompozisyonunu seçmek gereklidir. Kendimizi sadece yöneticilerle sınırlarsak, güvenilir bilgi toplamak mümkün olmayacaktır. Gelecekte kullanıcı olacak herkesin ankete dahil edilmesini tavsiye ederim. nihai sonuçlar. Örneğin, otomatik bir sistemin tanıtılmasından bahsediyorsak, kullanıcı olacak herkesi dahil etmeye değer. Bir pozisyondaki 10 çalışandan birinin, kalan 9 kişinin bilmediği bazı özel işlevleri yerine getirdiği zamanlar vardır (örneğin, yönetim için özel bir rapor hazırlar). Sorumlulukların daha fazla yeniden dağıtılmasından veya iş tanımlarının geliştirilmesinden bahsediyorsak, siz de aynısını yapmalısınız. Otomatikleştirilmiş bir sistemin müteakip uygulaması için anket metodolojisinin veya iş süreçlerinin bir açıklamasının doğru durum farklıdır. Elbette anketlerin yapısı aynı olabilir ama bu en en iyi seçenek. İş süreçlerini tarif ettiğimizde anketler genellikle daha çok genel karakter, Çünkü neyle karşılaşılacağı tam olarak bilinmiyor. Belirli bir otomatik sistemin tanıtılmasından bahsediyorsak, bu sistemin özelliklerini dikkate alan anketlere sahip olmak daha iyidir. Bu yaklaşım ile sistemin bu işletmeye uygun olmayan tüm darboğazlarını anında tespit edebilirsiniz. Kural olarak, hazır sistemleri uygulama yöntemleri, bu tür anketlerin mevcudiyetini sağlar. Bu tür anketler, bireysel muhasebe alanları (örneğin, sipariş muhasebesi, satış, fiyatlandırma) veya belirli pozisyonlar için geliştirilebilir ( Mali yönetmen, Örneğin). Soruların bileşimi yaklaşık olarak aynıdır.
Anketler	Anket, bireysel süreçlerin özelliklerini öğrenmek için uzmanlarla yapılan sözlü bir görüşmedir. Anketi sadece bir "buluş-konuşma" gibi görünmeyecek, daha organize olacak şekilde düzenlemek gerekiyor. Bunu yapmak için, sözde bir anket planı hazırlamak gerekir. Anketin size soru soran, diğer anketlerdeki bilgilerle çelişen veya bilgilerin yüzeysel olarak sunulduğu kısımlarını buna dahil edebilirsiniz. Soruların eklenmesi ve sadece kişisel deneyime dayalı olması tavsiye edilir. hatasız. İdeal olarak, bir ses kaydı üzerinde anlaşırsanız. Aynı aşamada, iş akışında sağlanan bilgilerin (hem birincil belge formları hem de çeşitli raporlar) eksiksizliğini izlemek gerekir.
Kilit iş süreçlerinin veya otomasyon alanlarının tanımlanması	Anket ve anketten sonra, temel iş süreçlerinin tahsisi hakkında sonuçlara varmak için yeterli bilginin olduğu makul bir şekilde değerlendirilebilir. Aslında, yalnızca önemli iş süreçlerini değil, hemen hemen her şeyi (katılımcıların bileşimi doğru seçilmişse) ayırmak zaten mümkün. İş süreçlerini belirleme konusu tamamen ayrı ve basit olmayan bir konudur. Burada öğrenmek zordur ve esas olarak deneyimle geliştirilir. Seçilen iş süreçlerinden bir liste (sınıflandırıcı) derlenmelidir. Hangilerinin daha derinlemesine araştırılması, hangilerinin ele alınmaması gerektiğine karar vermek ve önceliklendirmek o zaman mümkün olacaktır.
Ayrıntılı çalışma için temel sistem gereksinimlerinin, hedeflerin, proje başarı kriterlerinin, süreçlerinin formüle edilmesi	Bu aşamada şirketin faaliyetleri ile ilgili tüm birincil bilgiler toplanmalı, iş süreçlerinin bir listesi derlenmelidir. Şimdi hedeflere dönme zamanı, bunları belirtin, gerekirse şirketin ilk kişileriyle tartışın. Hedefleri formüle ederken, ulaşıldığında projenin başarılı olduğunu kabul edeceğimiz belirli göstergeler dikkate alınmalıdır. Otomatik bir sistemin tanıtılmasından bahsediyorsak, o zaman ayrı bir liste, kilit kullanıcılardan sistem için gereksinimleri vurgulayabilir. Bunu, tüm gereksinimlerin alt sistemlere göre gruplandırıldığı, her gereksinim için gereksinimin yazarının, ifadelerin ve önceliğin belirtildiği ayrı bir tablo şeklinde yapıyorum. Bu bilgiler, bir sistem dağıtım planı (bireysel alt sistemlerin uygulama sırası) ve ayrıca sistemin daha da geliştirilmesi için teklifler hazırlamak için kullanılabilir (mevcut projede bireysel alt sistemlerin uygulanması planlanmıyorsa). İş süreçlerinin tanımlanması gerekiyorsa, daha detaylı incelenmesi gereken süreçler hakkında kararlar verilir.

Böylece “Sırada ne var?” sorusuna geldik. Ayrıca, iş süreçlerini tanımlama ve İş Tanımını geliştirme görevlerini ayrı ayrı ele alacağız. Bu görevleri paralel olarak düşünmem tesadüf değil. Aralarında gerçekten de göstermek istediğim pek çok ortak nokta var. İlk olarak, iş süreçlerini tanımlarken iş sırasını göz önünde bulundurun.

	Ne ve nasıl yapılır
Bir iş süreci seçme	Önceki aşamalarda elde edilen genel iş süreçleri listesinden, ayrıntılı çalışma için (önceliğe göre) birini ayırıyoruz. Sonra diğerleriyle aynı şeyi yaparız.
İş sürecinin detaylı incelenmesi	Seçilen iş sürecini ayrıntılı bir incelemeye tabi tutuyoruz: alınan birincil belgeleri, raporları ve program sürecinde kullanılan yapılarını, çeşitli dosyaları (örneğin Excel) analiz ediyoruz, son uygulayıcılarla konuşuyoruz. Sürecin nasıl iyileştirilebileceğine dair çeşitli fikirlerin toplanması. İşlemi tam olarak yapıldığı koşullarda gözlemleyebiliyorsanız çok faydalıdır (izlenmeyi pek çok kişi sevmez ama ne yapmalı)
İş sürecinin grafiksel ve/veya metinsel açıklaması (birincil)	kabul edilmiş detaylı bilgiİşlemi anlatmadan önce grafik anlatım gerektirip gerektirmeyeceğine karar vermek gerekir. İşlem basit ve anlaşılırsa, içinde çok az işlev varsa ve grafiksel gösterim onun anlayışını veya algısını geliştirmeyecekse, o zaman bununla zaman kaybetmeye gerek yoktur. Bu durumda tablo halinde metinsel olarak anlatmak yeterlidir. Süreç, farklı mantıksal koşullara sahip karmaşıksa, grafik diyagramını vermek daha iyidir. Diyagramları anlamak her zaman daha kolaydır. Süreci grafik bir biçimde açıklamaya karar verirseniz, bu, onun metinsel açıklamasını sağlamanıza gerek olmadığı anlamına gelmez. Onlar. sürecin metinsel bir açıklaması her durumda olmalı ve aynı şemaya göre yapılmalıdır. Bunu, şunları belirtmek için bir tablo şeklinde yapmak uygundur: her adımın uygulayıcıları, girdide hangi bilgileri alırlar, her adımın açıklaması, çıktıda hangi bilgilerin üretildiği. Aşağıda bunun nasıl görünebileceğine dair bir örnek göreceğiz.
Sanatçılar ve iş sürecinin sahibi ile koordinasyon	En iyi yol bilgiyi sunma tarzını ne kadar iyi seçtiğinizi anlamak, sürecin kullanıcılarına (uygulayıcılarına) sonucu göstermektir.Böyle bir gösteride en önemli şey, sürecin nasıl yapıldığını ne kadar doğru anladığınızı anlamaktır. Proje ekibinin eğitimi başarılıysa, uygulayıcılardan oldukça yeterli geri bildirim bekleyebilirsiniz. Ve ilgilenirlerse, o zaman her şey çok daha hızlı hareket etmeye başlayacak Belirlenen açıklamalar ve tutarsızlıklar açıklamaya yansıtılmalıdır (güncellendi), gerekirse işlemi tekrarlayın.
İş süreci göstergelerinin tanımlanması	Bir iş sürecinin nasıl yürütüldüğüne dair iyi bir anlayışa sahip olduğunuzda, sürecin kalitesini veya hızını ölçebilen metrikler hakkında düşünmeniz gerekir. Kolay değil ama gerekli. Gösterge ölçülebilir olmalıdır, örn. sayısal olarak ifade edilir ve bu değeri elde etmenin kolay bir yolu olmalıdır. Ölçülen gösterge tanımlanamazsa, iş sürecinin yeterince tanımlanmamış olması riski vardır. Ayrıca süreçteki değişikliklerin iyileşmeye yol açıp açmayacağını anlamak (çünkü ölçülemez) mümkün olmayacaktır.
Nihai iş süreci belgeleri	Sürecin nasıl yapıldığını (veya yapılması gerektiğini) anladığımızdan emin olduktan sonra, bunu belgelere dahil edebiliriz.
	Daha fazla seçenek mümkündür: söz konusu süreçler analiz edilecek ve optimize edilecek, geliştirilecektir. iş tanımları, bireysel süreçleri vb. otomatikleştirme ihtiyacına ilişkin kararlar alınır. Ayrı bir proje de olabilir: iş süreçlerinin bir açıklaması.

Şimdi, bir bilgi sistemi için gereksinimleri inceleme yaklaşımının, Görev Tanımlarına daha fazla yansımasıyla nasıl görüneceğini düşünelim.

	Ne ve nasıl yapılır
Bir iş gereksinimini/otomasyon alanını vurgulama	Uygulamada gereklilikler (örneğin, "Envanter") olarak bütün bir otomasyon alanını ayırmak, ancak bu, gereksinimleri detaylandırmanın en etkili yolu değildir. Otomasyon alanı bir grup gereksinimdir ve bunları ayrı ayrı ele almak daha iyidir. Örneğin, "Malların depoya girişinin muhasebeleştirilmesi"
İş gereksiniminin ayrıntılı çalışması	Bir iş gereksiniminin detaylı bir şekilde incelenmesi, son kullanıcının onu nasıl görmek istediği ve (tabi ki projenin amaçlarına uygun olarak) kullanacağı şeklinde anlaşılır. Yazılım geliştirme teknolojilerinde buna genellikle "kullanım durumu" denir. Böylece, bir iş gereksinimine ilişkin ayrıntılı bir çalışma, kullanım durumlarının geliştirilmesine indirgenir. Böyle bir seçeneğin bir örneği, makalenin Ek 2'sinde verilmiştir. En basit durumlarda, kullanım durumlarını grafik diyagramlar şeklinde çizmek hiç gerekli değildir, ayrıca kendinizi metinsel formülasyonla sınırlayabilirsiniz. Örneğin, "Bir ürün girerken fiyat alış fiyatı + %20 olarak hesaplanmalıdır" şartı çekmek mantıklı değil. Ek 2'deki örnekte gösterildiği gibi, otomasyon kapsamına kadar birleştirilmiş gereksinimleri bir diyagram şeklinde sunmak mantıklıdır.
Bir bilgi sisteminde modelleme gereksinimleri	İşte burada! Muhtemelen hatırladığınız gibi, Görev Tanımlarını geliştirme metodolojisindeki bu en önemli unsura zaten dikkat etmiştim. "Bir model oluşturun - sonucu alın!" Ne modellenmelidir? Bir önceki aşamada elde edilen kullanım durumlarının modellenmesi gerekmektedir. Simülasyonun çıktısı ne olmalıdır? Sektör özelliklerini dikkate alarak, kullanıcı verilerinin girildiği ve tercihen (kullanıcı) işitme duyusuna aşina olduğu bir demo programı edinmelisiniz, gerçek problemler. Ve sadece girilmemiş, ancak bu verilerin nereden geldiği, nasıl hesaplandığı açık olmalıdır. Bu noktada okuyucunun şu soruları olmalıdır: Peki ya yeni bir sistem geliştirilmesi planlanıyorsa ve modellenecek hiçbir şey yoksa? Gösteri için yeterli işlevsellik yoksa ve sistemin iyileştirilmesi gerekiyorsa ne olacak? Elbette böyle bir durumla karşı karşıya kalmalısınız ve bu normaldir. Ne yapalım? Sistem tamamen yeniyse (“sıfırdan” dedikleri gibi), o zaman çoğunlukla kağıt üzerinde modellemeniz gerekecek, burada kullanım durumu diyagramları size çok yardımcı olacaktır. Kısmen, geliştirilmesi gereken (geliştirmenin gerçekleştirileceği ortamda) bazı ekran formlarının taslağını çıkarmak mantıklıdır, çünkü. onları bir düzenleyicide çizmek daha uzun sürer ve bu iş sıkıcıdır. Hazır bir sistem uygulanıyorsa ve işlevsellikten yoksunsa endişelenecek bir şey yok, veriler elle giriliyor ve kullanıcıya gerekli iyileştirmelerden sonra şu şekilde hesaplanması gerektiği söyleniyor ( ve görüyor). Kullanıcının boş zamanlarında bağımsız olarak modelle çalışmayı deneyebilmesi için, kısa da olsa böyle bir modele metinsel bir açıklama ile eşlik edilmesi tavsiye edilir. Aynı açıklamada, iyileştirmeler için gereksinimleri formüle edebilirsiniz.
Bilgi modelinin çalışma grubuna gösterilmesi	Ortaya çıkan modeli Müşteriye gösterir ve her şeyin nasıl çalışması gerektiğini söyleriz.Modeli alt sistemlerle göstermek daha iyidir, yani. gereksinim grubuna göre. Önerilen şemanın müşteri için işe yaramayacağı ortaya çıkarsa, diğer kullanım durumlarını düşünmeniz, modelde değişiklikler yapmanız ve tekrar göstermeniz gerekir. Yalnızca planlanan modelin belirli bir müşteriyle “yaşayacağına” dair güven varsa, model başarılı sayılabilir.
test geliştirme	Testlere neden ihtiyaç duyulur? Gereksinimleri nasıl uygulayabildiğimizin kontrol edilmesi gerekecek. Buna göre, tüm anahtar alanlar, karmaşık algoritmalar vb. için testler yapılması arzu edilir. Bu testler dahil olmak üzere işlerin teslimi sırasında kullanılabilir. Sistemin her fonksiyonu için test yapılmasına hiç gerek yok, her yerde sağduyu olmalı. Hazır bir sistemden bahsediyorsak, "müşteri dizinine yeni bir öğe girmek" için bir test yapmak aptalca görünecek ve atık güç ve zaman. Ancak bu tamamen yeni bir sistemse, bu oldukça mümkündür. Henüz bir sistem yoksa testler neden yapılır?İlk olarak, geliştiricinin ondan ne elde etmek istediği daha net olacaktır. İkinci olarak, test cihazı için hayatı kolaylaştırıyoruz (sonuçta birisi geliştirme sonucunu test edecek). Genel olarak test etmek ayrı bir disiplindir, birçok yöntemle çok basit değildir. Uygulamada, kural olarak, hala en basit test yöntemleri kullanılmaktadır.
Gereksinimlerin Görev Tanımı biçiminde belgelenmesi	Önceki aşamalarda toplanan bilgiler, gereksinimler bölümündeki "İş Tanımı" belgesinin temelinde yer alması gerekenler olacaktır, bu yüzden tüm bunları doğru bir şekilde düzenlemek kalır.
Projenin hedeflerine bağlı olarak diğer eylemler (veya bunların eksikliği)	Geliştirme süreci, proje için ortak arama, ihale vb. daha uzun sürebilir, hepsi duruma bağlıdır.

Evet, Görev Tanımının geliştirilmesi zaman alıcı bir süreçtir ve bu nedenle maliyetlidir. Ancak doğru yapılırsa, Müşteriyi karşılanmayan beklentilerden kurtarır. Yüklenici, Müşterinin istediğini yapmak ve aynı şeyi yüz defa tekrarlamamak zorundadır. Ve genel olarak, tüm projeye şeffaflık verir.