Teknik görev örneği nasıl yazılır? Sistemi oluşturmanın amacı ve amacı. Laboratuvar çalışması için hazırlık

Bu yazıda, İş Tanımı geliştirme sorununu ayrıntılı olarak ele almaya çalıştım. Konu, sorun kadar eskidir. Ancak yine de genellikle "nasıl gidiyor" olarak çözülür. Henry Shaw'ın dediği gibi, "Bizi en çok küçük şeyler endişelendirir: Bir filden kaçmak, bir sinekten kaçmaktan daha kolaydır."

Bu makale ne hakkında?

• İ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.

• 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 zor durumdur çünkü çeşitli koşullarda çalışmanız gerekir:
  • 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;

• İş Tanımı neden her zaman 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?

Teknik görev nedir?

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 bu belgelerin alaka düzeyi hakkında farklı görüşler var. 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 pratik sorunları ortaya çıkarmaz modern dizayn ve onları eleştirenler alternatif (somut ve sistemsel) sunmuyorlar.

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 tek sistem tasarım belgeleri. Ö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ı.

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).

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 özel;
3. gereklilik olmalıdır test edildi;

İş 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 başka bir şey var önemli nokta:

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

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 - bu, 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 doğrusu, bir mimar tarafından yönetilen bir grup uzman. Proje ne kadar büyük olursa, İş Tanımı üzerinde o kadar çok kişi çalışır.

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? Ancak pratikte, Görev Tanımı ile Teknik Tasarım arasında bulanık bir sınır var. 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ılmasını etkileyen önemli bir faktör daha vardır: hızlı gelişim hızlı geliştirme araçları ve geliştirme metodolojileri. 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ı belirli bir konuyu da tanımlayabilir. teknik çözüm gereksiniminin uygulanması. Ö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?

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ı

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. Sonuçta, Görev Tanımı henüz son belge, geliştirilecek olan. 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).

Gereksinimler beyanının Görev Tanımının ana bölümü olmasına ve bazı durumlarda Görev Tanımının tek bölümü haline gelmesine rağmen, bunun önemli bir belge olduğuna ve çizilmesi gerektiğine dikkat etmelisiniz. buna göre yukarı. 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ı.

Bölüm 1. genel bilgiler.

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?

Teknik görev nedir? Nasıl yapılır ve neden gereklidir? Örnekler, örnekler, ipuçları ve püf noktaları.

Mükemmel bir şekilde anlaşıldığınızda ne kadar harika görünüyor. Birkaç cümle verdi ve işte burada, tam da hayal ettiğiniz gibi. Ne yazık ki, bu şekilde çalışmıyor.

Bilgi algısı sorunu sonsuzdur. "Kırık telefon" etkisi yaygın bir durumdur. Ve bir görevi nasıl belirleyeceğinizi bilmiyorsanız ne diyeceksiniz? Evet, bu da olur ve bununla bir şekilde çalışmanız gerekir, ama nasıl? Belirlediğiniz görevlerin sonuçlarının beklentilerinizi karşılaması için görev tanımlarını yazınız.

teknik görev nedir

Görev Tanımı (veya TOR) - yüklenici tarafından sağlanan ürün veya hizmetler için müşterinin gereksinimlerini içeren bir belge. Basit kelimelerle: Öyle ve öyle istiyorum ki karşılıklı yedi dikey çizgi ve hatta bazıları kırmızı ve bazıları renksiz çizim olsun (malzemenin sonunda bu konuyla ilgili bir video, izlemenizi tavsiye ederim).

Tasarım Bölümü

Bu belge bir A4 sayfası veya tüm cildi alabilir, hepsi içinde yer alan görevlere ve isteklere bağlıdır. Örneğin, küçük bir açılış sayfası (tek sayfalık site) veya makine öğrenimi ve diğer özelliklere sahip karmaşık yazılımlar için teknik bir görev yazabilirsiniz.

Neden teknik bir göreve ihtiyacınız var?

• Sanatçılar için görevi ayarlamak için.
• Sonunda ne elde etmek istediğinizi ayrıntılı olarak açıklamak için.
• İş sırasını kabul etmek.
• Uygulama sonrası çalışmaları değerlendirmek ve kabul etmek.
• Kime ... (seçeneklerinizi yorumlara ekleyin).

Aslında, teknik görevin yukarıdaki listeden çok daha fazla randevusu ve avantajı vardır. Şahsen benim için TK'nin çözdüğü ana görev, ihtiyacım olanı beklentilerden (beklentilerimden) minimum sapma ile uygulamaktır.

TK sayesinde, uygulama süresi, para ve nihai ürün veya hizmetin beyan edilen özelliklerine uygunluğu hakkında her zaman soru sorabilirsiniz.

Aslında bu, müşteri ve yüklenici tarafından hazırlanan ciddi bir belgedir. Tarafların ceza ve yükümlülüklerinin belirlendiği noktaya kadar. Bir dizi GOST vardır, Habré hakkında daha fazlasını okuyun.

Teknik özelliklerin geliştirilmesi

Oyundan "yetişkin bir şekilde" bahsediyorsak, örneğin, geliştirme için görev tanımı mobil uygulama veya bir web sitesi, o zaman bu, çok para ödenen ayrı bir çalışmadır. Bir kişiyi, genellikle eski veya şimdiki bir Baş Teknik Sorumluyu getirirsiniz ve ondan size yardım etmesini istersiniz.

sakal isteğe bağlıdır

Projenin / görevlerin hacmine bağlı olarak, bu kişi tüm "Dilek Listenizi" toplar, bunları dile çevirir. teknik dil, belki eskizler hazırlar (yaklaşık olarak nasıl görünmesi gerektiği) ve size bitmiş belgeyi verir. Daha sonra bu belgeyi sanatçılara (şirketinizin içindeki bir ekip veya dış kaynak kullanımı için) aktarır, para, şartlar üzerinde anlaşır ve işe koyulursunuz.

İpucu: CTO ekibinizde olmalıdır, aksi takdirde büyük olasılıkla uygulama sürecinde bir şey fark etmeyeceksiniz. Her şey için yeterli bilgiye sahip değilsiniz. TK'nın yazımına kimler katıldı, kontrol ediyor.

şartname nedir

Her şey seçtiğiniz şablona bağlı olacaktır (biraz sonra şablonlara/örneklere bazı bağlantılar vereceğim), ancak iş tanımına dahil edilen temel bloklar vardır:

1. Projenin/görevin açıklaması. Ne tür bir proje veya görevin tamamlanması gerektiğini kısaca yazıyoruz.
2. Amaç ve hedefler. Projenin hedefleri nelerdir?
3. Gereksinimler. Tasarım, özellikler, ihtiyaç duyulan teknolojiler.
4. Eserlerin tanımı. Ne, ne zaman ve nasıl yapılacak.
5. Kontrol ve kabul prosedürü. İşin nasıl kabul edileceği, nelerin tamamlanmış sayılabileceği.
6. Uygulamalar. Eskizler, eskizler, prototipler.

İşin maliyeti genellikle ayrı uygulama sözleşmeye, ancak taraflar görev tanımının kendisinde miktarları belirlediklerinde gerçekleşir.

Okumamı böldüğüm için beni bağışlayın. Telegram kanalıma katılın. Yeni makale duyuruları, dijital ürünlerin geliştirilmesi ve büyüme hilesi, her şey orada. Seni bekliyor! devam ediyoruz...

Görev tanımı örnekleri

Teknik özelliklerin geliştirilmesi karmaşık ama çok ilginç bir süreç olmasına rağmen. Göreviniz, nihai sonucun bir resmini yeniden oluşturmak ve ardından bunu parçalar halinde açıklamaktır.

Smart TV uygulamasını güncellemek için teknik özelliklerimden birine bir örnek. Daha karmaşık ve karmaşık ürünler için görevler, teknik departmandaki meslektaşların yardımıyla zaten derlenmişti. Ortaklarınızdan yardım istemekten çekinmeyin, onları mümkün olduğunca sık sürece dahil edin. Ve geri bildirim vermeyi unutmayın! Sonuçlarını bilmeden bir şeye zaman ve çaba harcamaktan daha kötü bir şey yoktur. Bize kişinin tavsiyesinin işinizde nasıl yararlı olduğunu söyleyin, aksi takdirde tek taraflı bir oyun olur.

Bir çevrimiçi mağazanın geliştirilmesi için görev tanımı

Bir mobil uygulamanın geliştirilmesi için görev tanımı

Sitedeki TK

Hizmetler/güncellemeler için İş Tanımı

Daha fazla örneğe ihtiyacınız varsa, google'da aramanız yeterlidir.

Ana öneri, bunu yapmaktır. Sorun şu ki, anne tembelliği herkesi alt ediyor ve ona direnmek kolay değil. Tüm iradenizi bir yumruk haline getirin ve görev tanımlarını yazmaya başlayın, sadece yazın ve durmayın. "Mükemmel" gitmez diye endişelenme, bir sır vereceğim, bu olmaz. Sadece yaz, her seferinde daha iyi ve daha iyi olacak.

Böyle olması gerekiyor

Teknik özellikleri yazmanın ilk temelleri birkaç yıl önce ortaya çıkmaya başladı. Tasarımcılarla çalıştım ve reklam kampanyaları için reklam öğeleri oluşturma görevini belirledim. Tutarsız istemek ve bir sürü boşa harcanan zamana ve açıklamalara dönüştü. Zamanla, görevlerin ayarlanması bir tür anlamsal bloklara ve ardından bir tür teknik göreve dönüşmeye başladı.

Örneğin, "Sitedeki beğen düğmesi" görevi için:

1. Açıklama: Sitemizde "Beğen" butonu oluşturmanız gerekmektedir.
2. Amaç ve hedefler: kullanıcı katılımı, beğeni sayısına göre materyallerin verilmesi / derecelendirilmesi.
3. Gereksinimler: böyle bir tasarım (örnek: benzer bir şeye bağlantı), işlevsellik (herhangi bir kullanıcı resmi derecelendirebilir ve beğenebilir, site sistemi beğeni sayısını dikkate alır ve malzemelerin çıktısını değiştirir), teknoloji (masaüstünde mevcuttur) Ve mobil versiyonlar alan).
4. İşin tanımı: düğme düzenleri için 3 seçenek çizin (tamamlanma tarihi: 10/01/17), beğenilere göre materyal vermek için bir sistem geliştirin (tarih: 14/10/17), işlev testi (tarih: 10/16/17) , yayın (tarih: 10/17/17)
5. Eserlerin kabulü: Kullanıcı beğen butonuna tıklar, sistem tıklamayı sayar, malzemelerin teslimi değişir.
6. Uygulamalar: eskizler, eskizler, benzer bir işlevin çalıştığı proje örnekleri.

Yapının görevleriniz için gerekli olan bölümlerini ve kısımlarını kendinize bırakın. Örneğin, altıncı blok olan “Uygulamalar” fonksiyonel gereksinimlerde açıklanabilir. Ana tavsiye: görevi, görev tanımının yapısına göre şu ya da bu şekilde tanımlayın. Böylece önemli anları kaçırmaz, gereksiz sorulardan kendinizi kurtarır, iş arkadaşlarınızın hayatını kolaylaştırırsınız.

Hadi bakalım

Teknik bir görevin ne olduğunu ve nasıl yapılacağını analiz ettik. Artık net ve net bir şekilde hedefler belirleme, düşüncelerinizi diğer insanlara iletme ve ek açıklamalar için zaman kazanma yeteneğine sahipsiniz. Umarım artık tüm bunlarla ne yapacağınızı biliyorsunuzdur.

Referans şartları, bir bilgi sistemi veya başka bir ürün oluşturmak için kaynak materyaldir. Bu nedenle iş tanımı (kısaltılmış TOR) öncelikle ürün için temel teknik gereklilikleri içermeli ve bu sistem ne yapmalı, nasıl ve hangi koşullarda çalışmalı sorusuna cevap vermelidir.

Kural olarak, görev tanımı hazırlama aşamasından önce bir anket yapılır. konu alanı, bir analitik raporun oluşturulmasıyla sona erer. Görev Tanımı belgesinin temelini oluşturan analitik rapordur (veya analitik nottur).

Müşterinin gereksinimleri raporda özetlenebilir ve UML diyagramları ile gösterilebilirse, görev tanımı sistem için tüm işlevsel ve kullanıcı gereksinimlerini ayrıntılı olarak açıklamalıdır. Görev tanımı ne kadar ayrıntılı olursa, kabul testleri sırasında müşteri ile geliştirici arasında o kadar az anlaşmazlık çıkacaktır.

Bu nedenle iş tanımı, hem geliştiricinin hem de müşterinin nihai ürünü sunmasını ve ardından gereksinimlere uygunluğu kontrol etmesini sağlayan bir belgedir.

Görev tanımlarını yazmak için yol gösterici standartlar, GOST 34.602.89 "Otomatik Sistem Oluşturmak için Görev Tanımı" ve GOST 19.201-78 "İş Tanımı"dır. İçerik ve tasarım gereksinimleri. İlk standart, otomatik sistem geliştiricileri için, ikincisi ise yazılım araçları(“GOST Nedir” makalesinde bu seriler arasındaki farkı tartıştık).

Bu nedenle, aşağıda, görev tanımının GOST'lere göre içermesi gereken bölümlerin bir listesini ve açıklamasını sunuyoruz.

Bu nedenle, Görev Tanımı belgesi, aslında, otomasyon nesnesinin analitik çalışması aşamasında tanımlanan, tasarlanan ürün için tüm gereksinimleri yansıtmalıdır.

Yukarıdaki tabloya dayanarak, görev tanımının ana bölümlerini vurgulayabiliriz:

• Sistem (program) hakkında genel bilgiler;
• Sistemin (programın) amacı, amaçları ve hedefleri;
• Sistem gereksinimleri (fonksiyonel gereksinimler, kullanıcı gereksinimleri, bir bütün olarak sistem gereksinimleri, vb.);
• Teminat türleri için gereklilikler;
• Dokümantasyon gereklilikleri;
• Gelişim aşamaları ve aşamaları;
• Sistemin (programın) kontrol ve kabul sırası.

Genel bilgi
İş Tanımı belgesinin bu bölümü, sistemin tam adını ve belge geliştirmede kullanılacak tüm kısaltmaları içermelidir.

Örnek:

"İÇİNDE bu belge oluşturulmakta olan bilgi sistemi, SW olarak kısaltılan "Eğitim Kaynaklarına Erişim için Tek Pencere" olarak adlandırılır.
Eğitim Kaynaklarına Erişim için Tek Pencere sistemi bundan sonra Tek Pencere veya Sistem olarak anılacaktır.

Ayrıca, geliştirmede yer alan kuruluşların (Müşteri ve Yüklenici) ayrıntılarını bildiren alt bölümleri de içermelidir.

Görev Tanımı belgesinin "Geliştirmenin temelleri" alt bölümü, bu çalışmaların temelinde gerçekleştirildiği ana belgeleri listeler. Örneğin, bir ülkenin Hükümeti veya başka bir Devlet organı tarafından yaptırılan bir sistem için, Hükümetin kanunları, kararnameleri ve kararları belirtilmelidir.

Görev Tanımı belgesinin ayrılmaz bir parçası da terimler ve kısaltmalar listesi olmalıdır. Terimler ve kısaltmalar en iyi şekilde "Terim" ve "Tam biçim" olmak üzere iki sütun içeren bir tablo şeklinde sunulur.

Terimler ve kısaltmalar şurada bulunur: alfabetik sıra. Her şeyden önce, Rusça terimlere ve kısaltmalara, ardından İngilizce terimlere bir kod çözme vermek gelenekseldir.

Sistemi oluşturmanın amacı ve hedefleri

İş Tanımı belgesinin bu bölümü, sistemin oluşturulma amacını ve hedeflerini içermelidir.

Örnek:

“Eğitim Kaynaklarına Erişim için Tek Pencere” bilgi sistemi, kullanıcılara Rusya Federasyonu eğitim sistemi, eğitim kurumlarının işlevini yerine getiren kuruluşlar hakkında eksiksiz, operasyonel ve uygun bilgiler sağlamak için tasarlanmıştır.

Sistemin temel amacı birleşik bir oluşumun oluşturulmasıdır. bilgi ortamı ve Rusya Federasyonu'ndaki eğitim kurumlarının iş süreçlerinin otomasyonu.

"Tek Pencere" bilgi sisteminin oluşturulması şunları sağlamalıdır:

• kullanıcılara çok çeşitli bilgi kaynakları sağlamak;
• Seviye atlamak bilgi Güvenliği;
• bir dizi iş sürecini optimize ederek eğitim kurumlarının ve bölümlerinin verimliliğini artırmak;
• departman içinde bilgi sistemleri ve hizmetler arasındaki etkileşim sürecinin verimliliğini artırmak.

Sistemin oluşturulması, departman verimliliğinin artması sonucunda işletme maliyetlerinin düşmesini sağlayacaktır.”

sistem gereksinimleri

Görev Tanımı belgesinin bu bölümü, sistemin temel işlevsel gereksinimlerini açıklamayı amaçlamaktadır. Bu, iş tanımının en önemli kısmıdır, çünkü sistemi devreye alma sürecinde Müşteri ile olan anlaşmazlıklarda ana argümanınız olacaktır. Bu nedenle, yazımına en dikkatli şekilde yaklaşmak gerekir.

Görev Tanımı belgesi, otomasyon nesnesinin analiz aşamasında belirlenen tüm gereksinimleri içermelidir. İşlevsel gereksinimlerin tanımı yoluyla ifşa edilmesi gereken ana iş süreçlerini vurgulamak en iyisidir.

Örnek:

"4.1 İş süreci" Rusya Federasyonu eğitim kurumları hakkında bilgi sağlanması

Bu iş sürecinde aşağıdaki katılımcılar ayırt edilir:

Moderatör - Sistemin hizmet personelinin bir parçası olan ve sağlanan verilerin doğruluğundan sorumlu olan departman çalışanı

Kullanıcı - Rusya Federasyonu'ndaki eğitim kurumlarının çalışmaları hakkında bilgi alması gereken bir vatandaş.

4.1.1 Bir eğitim kurumunun Sisteme kaydı

Rusya Federasyonu'ndaki bir eğitim kurumunun kaydı, kurumun sorumlu bir çalışanı tarafından gerçekleştirilir (“Hükümet Kararnamesi ...”).

Bir eğitim kurumuna kayıt olma süreci aşağıdaki adımları içerir:

• Yazar bir kuruluş kaydı oluşturur;
• Yazar, kuruluşun verilerini girer;
• Sistem, bu kuruluş için bir lisans olup olmadığını kontrol eder

• Veritabanında lisans varsa, Sistem Yazara başarılı kayıt hakkında bir mesaj gönderir;
• Veritabanında lisans bulunamazsa, Sistem Yazara bu kuruluş için lisans bulunmadığına dair bir mesaj gönderir.

Zaman izin verirse, bu bölümde sağlanan bilgiler Görev Tanımı belgesinin ekinde daha ayrıntılı olarak açıklanmalıdır. Kullanım koşulları ekinde bir ekran formu getirebilir ve üzerinde bulunan tüm olayları (oluşturma, görüntüleme, düzenleme, silme vb.) Aşağıda açıklayabilirsiniz.

Bir bütün olarak sistem için gereksinimler, tüm alt sistemlerin bir açıklamasıyla birlikte mimarisinin açıklanmasını içerir. Görev Tanımının bu bölümü, sistemin diğer ürünlerle (varsa) entegrasyonu için gereklilikleri açıklamalıdır. Ayrıca, görev tanımı aşağıdakileri içermelidir:

• sistem çalışma modları için gereksinimler
• hedef göstergeleri
• güvenilirlik gereksinimleri
• güvenlik gereksinimleri
• personelin sayısı ve nitelikleri ile çalışma biçimleri için gereklilikler
• bilgi güvenliği gereksinimleri
• kaza durumunda bilgilerin güvenliği için gereklilikler
• patent izni gereksinimleri
• standardizasyon ve birleştirme gereksinimleri
• vesaire.

Teminat türleri için gereklilikler

İş Tanımı belgesinin bu bölümünde, matematiksel, bilgi, dil, yazılım, teknik ve (varsa) diğer destek türleri için gereksinimler sunulmalıdır.

Dokümantasyon Gereksinimleri

Görev tanımının "Dokümantasyon Gereksinimleri" bölümü, müşteriye sağlanması gereken tasarım ve işletim belgelerinin bir listesini içerir.

Görev tanımının bu bölümü, işlevsel gereksinimlerin açıklaması kadar önemlidir, bu nedenle "Müşteriye GOST 34 uyarınca tüm belgeler sağlanmalıdır" ifadesiyle sınırlandırılmamalısınız. Bu, "Form", "Pasaport" vb. dahil olmak üzere tüm belge paketini sağlamanız gerektiği anlamına gelir. GOST 34.201-89'da belirtilen listedeki belgelerin çoğuna ne siz ne de müşteri ihtiyaç duymaz, bu nedenle Görev Tanımı belgesini geliştirme aşamasında liste üzerinde hemen anlaşmak daha iyidir.

Minimum belge paketi genellikle şunları içerir:

• Teknik görev;
• Taslak (teknik) tasarım beyanı;
• Teknik Tasarıma ilişkin açıklayıcı not;
• kuruluşun açıklaması bilgi bankası;
• Kullanici rehberi;
• Yönetici Kılavuzu;
• Program ve test metodolojisi;
• Kabul testi raporu;
• İş bitirme belgesi

Görev tanımındaki belgelerin listesi en iyi şekilde, belgenin adını ve geliştirilmesi gereken standardı gösteren bir tablo şeklinde sunulur.

Gelişim aşamaları ve aşamaları

Görev Tanımı belgesinin bu bölümünde yapılacak işin tüm aşamaları hakkında bilgi verilmelidir.

Aşamanın tanımı, işin adını, terimlerini, tanımını ve nihai sonucu içermelidir.

Sistemin kontrolü ve kabulü için prosedür

İş Tanımı belgesinin bu bölümünde, kabul testlerinin hangi esasa göre yapılması gerektiği belgenin belirtilmesi gerekir.

Gerekirse, görev tanımı diğer bölümlerle tamamlanabilir veya uygun olmayan maddeler çıkarılarak azaltılabilir.

Görev tanımının yapısını değiştirirken, çelişki durumlarından kaçınmak için, belgenin geliştirilmesinden önce müşteri ile kararlaştırılmalıdır.

Bu metin tamamen, yazarın kendisinin ve hepinizin gelecekteki müşterilerinize, meslektaşlarınıza, akrabalarınıza ve tanıdıklarınıza şu soruya standart bir yanıt biçiminde güvenle gönderebileceği kalıcı bir bağlantının varlığı uğruna oluşturulmuştur: "TK'nıza ihtiyacım var mı ve genel olarak bu ne?"

Dedikleri gibi - "bin kelime yerine", çünkü bu konuda Skype'ta 4-5 saat boyunca müjdeleme her seferinde zaten sıkıcı hale geliyor ve yıllar içinde "Görev Tanımı" tanımı altında açık sözlü saçmalıkların kaymasına yönelik küresel eğilim sadece şiddetlenir.

Sorun

Gerçek şu ki, bir terimin belirli bir biçiminin yanı sıra açık ve anlaşılır bir tanımı olduğunda, kendi özetleri, prototipleri, icat edilmiş anketleri, açıklamaları ve basitçe gelen başvuruları için tüm manipülasyonlar ve ikameler en azından profesyonelce görünmüyor. Bu nedenle, konseptimizin bilimsel tanımıyla başlıyoruz:

Görev Tanımı - teknik bir nesnenin (ürün) tasarımı için orijinal belge. Görev Tanımı, geliştirilmekte olan nesnenin ana amacını, 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 reçeteyi belirler. özel gereksinimler olarak. Görev tanımı yasal bir belgedir - tasarım işi için müşteri ile yüklenici arasındaki sözleşmeye bir ek olarak dahil edilir ve temelidir: amaç, hedefler, ilkeler dahil olmak üzere işin prosedürünü ve koşullarını belirler, beklenen sonuçlar ve son tarihler. Yani, şu veya bu iş öğesinin yapılıp yapılmadığını belirlemenin mümkün olduğu nesnel kriterler olmalıdır. İş Tanımı metnindeki tüm değişiklikler, eklemeler ve açıklamalar müşteri ile mutabık kalınmalı ve kendisi tarafından onaylanmalıdır. Bu aynı zamanda gereklidir, çünkü tasarım problemini çözme sürecinde yanlışlıklar veya hatalı başlangıç ​​​​verilerinin keşfedilmesi durumunda, geliştirmeye dahil olan tarafların her birinin suçluluk derecesinin, meydana gelen kayıpların dağılımının belirlenmesi gerekli hale gelir. bununla bağlantı. Görev tanımı, bilgi teknolojisi alanında bir terim olarak, icracıların bir yazılım ürünü, bilgi sistemi, web sitesi, portal veya diğer BT hizmetini geliştirmesi, uygulaması veya entegre etmesi için gerekli görevleri belirlemek için gerekli kapsamlı bilgileri içeren yasal olarak önemli bir belgedir.

Anlaşılır bir dile çeviriyoruz

1) Görev Tanımı - görevi belirler. Bu, bir prototip, eskiz, test, tasarım projesinden önce gelmesi gerektiği anlamına gelir, çünkü herhangi bir zihin haritası, veri akış şeması, mimari zaten belirli bir görevin yerine getirilmesidir, bu bir sorunun cevabıdır. Ve sorunun kendisi henüz tüm taraflarca sorulmadan, formüle edilmeden ve imzalanmadan önce - herhangi bir cevap a priori yanlış olacaktır, değil mi? Bu nedenle, herhangi bir proje üzerinde herhangi bir çalışmanın başlangıcı, sorunun bir ifadesidir ve onu çözmek için bir düzine seçeneğin ana hatlarını çılgınca aramak değildir.

2) Aslında, mantıksal olarak ilk paragraftan yeni bir tane çıkar - TK metninin kendisi, dünyadaki entropiyi artırmaya yönelik tüm bu sonraki girişimin hangi iş hedeflerini izlediğini açıkça formüle eden “Amaçlar ve Hedefler” bölümü ile başlamalıdır. Herhangi bir sorunu çözmeyen, hiçbir sonuca varmayan ve "can sıkıntısından" yapılan amaçsız bir görev - resmi olarak Görev Tanımı olarak kabul edilmez ve bundan böyle "sıradan bir kağıt parçası" statüsündedir.

3) Önerilen tasarım konseptinin veya etkileşimli prototipin veya hatta kullanıma hazır bir sitenin yukarıdaki iş sorununu çözüp çözmediğini nasıl anlayabilirsiniz? Hiçbir şey yapılamaz, tanıma tekrar dönmemiz gerekecek: “tanımlar ... beklenen sonuçlar ve son tarihler. Yani, şu veya bu iş kaleminin yapılıp yapılmadığını belirlemenin mümkün olduğu objektif kriterler olmalıdır.” Yani, ruble, saniye, ton-kilometre veya santigrat derece cinsinden net ölçülebilir göstergeler olmadan TK olamaz. Özet kutusu veya bir prototip veya başka herhangi bir saçma kağıt parçası, ancak Görev Tanımı değil.

Buradan, bu Görev Tanımında, aynı göstergeler alındığında, ölçüldüğünde ve taraflar ya el sıkıştığında ya da projeyi yeniden işleme için gönderdiğinde, “Kabul ve değerlendirme prosedürü” bölümü olması gerektiği sonucuna varıyoruz.

4) İş Tanımı, müşterinin genel iş planı, iş geliştirme stratejisi ve pazar segmenti analizi ile mutlaka tutarlı olmalıdır. Tüm bunlar, doğru hedefleri belirlemenize, doğru ölçümler elde etmenize ve buna göre bitmiş bilgi ürününü yeterince kabul etmenize olanak sağlayacak olan şeydir. Müşteri tarafından bir iş planının bulunmaması, Görev Tanımının profesyonel olmayan bir şekilde uygulanmasını otomatik olarak garanti eder.

Dış kaynaklı stüdyo, işletmenin iş hedeflerini ve ölçülebilir göstergelerini sahibinden daha iyi biliyor mu? Açıkçası hayır, bu da doğru İş Tanımının Yüklenicinin çalışanları tarafından değil, Müşterinin temsilcileri tarafından yazılması gerektiği anlamına gelir. Oyuncunun kendisine bir görev belirlemesi, sonra onu değerlendirmenin yollarını bulması ve sonunda yapılan iş için kendisine son notu vermesi saçmadır. İdeal olarak, böyle bir "girişim faaliyeti" olmamalıdır, ancak pratikte bu tam olarak her yerde olan şeydir, bunun sonucunda Görev Tanımı projeye gerekli yardımı sağlamaz, çoğu zaman esasen hayali bir belgedir. Bu şekilde yapma.

5) Bitmiş TK'daki her değişikliğin maliyeti olmalıdır. Taraflardan birinin fikrini değiştirmesi, yeterince uyumaması, aniden para biriktirmeye karar vermesi vb. İş Tanımı'ndaki her değişikliğin maliyeti de uygun bölümde önceden açıkça belirtilmelidir.

Bu arada, teorik olarak, tıpkı tasarımdaki her düzenlemede olduğu gibi veya sayfalar veya işlevler listesinde değişiklik yapmanın net bir fiyatı olmalıdır ve bu fiyat, yapım başlamadan önce peşin ödenir. bu değişiklik. Şahsen ben, onaylanmış Görev Tanımının herhangi bir revizyonunun toplam proje bütçesinin %30'u olarak tahmin edilmesini öneriyorum, ancak aksini de yapabilirsiniz.

İş Tanımında, geliştirme için zaman çerçevesini ve toplam bütçeyi ve ayrıca mevcut tüm kaynakların ve kısıtlamaların bir listesini önceden belirtmenin basitçe gerekli olduğunu söylemeye değer mi? Hayır, bu çok açık olurdu.

Peki ne yapıyoruz? Ne için? Ne yaptığımızı nasıl bilebiliriz? Her pivotun değeri ne kadar? - Bir kağıda yazılan tüm bu soruların cevapları, en başarısız projeyi bile çekip çıkarabilecek “sihirli değnek” gibidir.

Kontrol soruları

1) Öyleyse, Görev Tanımını yazmak için resmi bir GOST var mı? - Evet, hatta birkaç tane.

2) Ve ne, açıklama Görev Tanımında yer almıyor istenen sayfalar, düğme sayısı, kullanılan kitaplıklar, yönergeler vb. - İş Tanımının kendisinde değil, ancak Uygulamalarda tüm bunları elbette yukarıdaki hedefler, kısıtlamalar ve elde edilen sonucu daha fazla değerlendirmek için yöntemlerle ayarlayarak koyabilirsiniz. En azından gelecekteki tüm içeriği, en azından tipik karakterlerin bir açıklamasını yayınlayın - ancak görevin net bir ifadesi yerine değil, ondan sonra.

3) Yani belki buna ihtiyacım yok? - Belki de bugün binlerce site, tıpkı dünyadaki binlerce insanın doğuştan kör olarak mükemmel bir şekilde yaşaması gibi, teknik özellikler olmadan yapılmıştır. Ancak nereye gittiğinizi genel olarak görmek, bilinçli kararlar vermek ve elde edilen sonuçları bağımsız olarak değerlendirmek istiyorsanız, o zaman teknik özellikler olmadan yapamazsınız.

4) Yani siz ve Wikipedia, TK'nin müşteri tarafından oluşturulduğunu yazıyorsunuz. Ama nasıl olduğunu bilmiyorum / zamanım yok / sadece kendim yapmak istemiyorum. Nasıl olunur? - Teknik özelliklerin geliştirilmesini, işinizi, görevlerini, hedef kitlesini ve ihtiyaçlarını oldukça iyi bilen ve aynı zamanda web geliştirmenin tüm aşamalarından tamamen haberdar olan bir üçüncü tarafa verin. Bu üçüncü taraf bir tür "web noteri" olacak, yani yüklenicinin ihtiyacınız olan göstergeleri hafife almayacağının veya son teslim tarihlerini geciktirmeyeceğinin ve müşterinin ulaşılabilir metrikler belirleyeceğini ve oluşturulanları öznel olarak değerlendirmeyeceğinin garantisi olacaktır. nihai kabulde ürün, hareket halindeyken daha önce kaydedilenleri değiştirerek.

5) Peki ya TK yasal bir belgeyse, o zaman taşeronu dava edebilirim, ona ödeme yapamaz, onu her şeyi onuncu kez yeniden yapmaya zorlayabilirim? - Belge doğru bir şekilde hazırlanmışsa, başarılarını değerlendirmek için hedefler ve metodoloji belirtilir; belge taraflarca imzalanmışsa ve Sözleşmede belirtilmişse (Görev Tanımı bir sözleşme değildir), o zaman elbette yapabilirsiniz. Ancak her zamanki özet, prototipler, sanat-yaratıcı düzen, FL'de Güvenli Anlaşma ile - artık yok.

6) Bana işin bir tür scrum veya çevik olarak yürütüleceğini söylüyorlar; bu da artık arkaik TK'ye ihtiyacım olmadığı anlamına geliyor. Bu doğru? - Kendinize hakim olun: size anlaşılmaz bir kelime diyorlar, belli ki bir şeyi maskeliyorlar ve şimdi, size aşina olmayan bir terime dayanarak, yasal olarak yetkin ve hedefler ve ölçütlerle dolu bir belgeyi terk etmeyi teklif ediyorlar. Agile'ın kendisi "yıl sonuna kadar en az 10.000 ziyarete ulaşmak" veya "siteden bir ayda 25'ten fazla siparişe ulaşmak" gibi hedefler belirleyemez - bu belirlenemez, sadece toplantı yapmanın bir yolu Ve yeni organizasyon umursamaz çalışanlar Birkaç kez düşünün: “Gözlerine toz mu atıyorlar?”. Aslında, profesyonel TK herhangi bir yeni çıkmış Scrum'a zarar veremez, ancak kesinlikle yardımcı olacaktır.

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 Görev Tanımını geliştirmesi ve geliştirmesi için üçüncü taraf bir kuruluşa vermesi gerekir;
• Ticari bir kuruluş, otomatikleştirilmiş bir sistem uygulamaya karar verdi. Kendi BT hizmeti vardır. Bunu yapmaya karar verdik: bir İş Tanımı geliştirmek, ardından bunu BT hizmeti ile ilgili taraflar arasında koordine etmek ve kendi başımıza uygulamak;
• 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 zor durumdur çünkü çeşitli koşullarda çalışmanız gerekir:

  • 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 profesyonel yazılım geliştirme işindeyim ve birlikte çalışmak zorunda olduğum herhangi bir geliştirme ekibinde İş Tanımı sorusu ortaya çıktığı için kendimden çok emin konuşuyorum. 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. Çalıştığım yıllar boyunca, hem bireysel uzmanlar hem de seçkin ekipler ve danışmanlık şirketleri tarafından derlenen birçok teknik dokümantasyon çeşidi 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ğer birçok ilginç şirket gibi canavarlarla ilgili belgeleri görmek zorunda kaldım. 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 bu belgelerin alaka düzeyi hakkında farklı görüşler var. 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. (örneğin, inşaatta bir tasarım görevi, bir savaş görevi, ev ödevi, bir sözleşme edebi eser vb.) e.)"

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).

İşlevsellik için iyi formüle edilmiş gereksinimlerin başarılı bir Görev Tanımı için anahtar olduğunun sizin için açık olduğunu düşünüyorum. 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 özel;
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, İş Tanımı üzerinde o kadar çok kişi çalışır.

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? Ancak pratikte, Görev Tanımı ile Teknik Tasarım arasında bulanık bir sınır var. 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.

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

Genel olarak, hedefleri belirleme, 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 gereksinimler;
• standardizasyon ve birleştirme gereksinimleri;

Ana bölüm kesinlikle özel gereksinimleri olan (işlevsel) bölüm olsa da, bu bölüm de büyük önem taşıyabilir (ve çoğu durumda öyledir). Neler önemli ve faydalı olabilir:

• Kalite gereksinimleri. Geliştirilmekte olan sistemin uzmanların yeniden eğitilmesini gerektirmesi mümkündür. Bunlar, hem gelecekteki sistemin kullanıcıları hem de onu desteklemek için ihtiyaç duyulacak BT uzmanları olabilir. 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 temel 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;
• Herhangi bir ekipmanla entegrasyon varsayılır ve gereklilikler uygulanır (ö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şletmelerin 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 yerel bir ağı, sistemin çalışmadığı eski bir bilgisayar filosu yoktur.

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. İşte bu kadar, işinizi almak istemiyor. Kimin pahasına yönergeler geliştireceksiniz? Birçok takım bu kancaya şimdiden 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? öyle görünüyor basit şey, ancak herhangi bir 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;
• Kullanmak daha fazla şema, grafikler, tablolar, çizimler - böylece 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:

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ıdaki işlemi daha fazla yapmaya çalışalım sistem yaklaşı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. Biz şu an bireysel aşamaların yöntemlerini ve araçlarını incelerken göz önünde bulundurduğunuzdan emin olun. 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.

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.

Ş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.

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.