Стандарти

Това малко като тъпа тема за есе, ама какво да правя...

Интересуват ме всякакви мнения по въпроса.
Вариации бол:

- да се спазват или не
- да се чака разни хора и организации да се натуткат да приемат някой стандарт, или да се пише, както си реши софтуерната фирма. Какви са рисковете.
- какво става преди приемане на стандарт
- какво става после
- от кого се налагат тенденциите, какво се взема предвид
- как действа самата разработка на стандарти....

Малко съм лаконична. Простете.

Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...

ако имаш около 90% от пазара, нито чакаш нито ти пука
ако не ривеш, що не се спазват

Това, което ще ти кажа, не е отговор, а размисъл

- да се спазват или не:

Ако са добри - да се спазват. Стандартите дават преди всичко структурираност на проблемната област и готов начин да се правят нещата в нея.

Например, .doc носи със себе си идеи за организиране на документите, какво може да има и какво не в него, предоставя механизми за запазване на макроси и какво ли още не.

Така че ако няма някакъв принципен недостатък в самия стандарт, значи той върши работа и няма технологична причина да не се спазва. Разбира се, може да има други, нетехнологични причини, налагащи създаването на нов стандарт, но това не е тема на разговора ни

- да се чака ли някой да го направи

Ако разбираш достатъчно от нещата, които правиш, в общият случай няма причина да чакаш. Какъвто и стандарт да измислят хората, той едва ли ще е принципно несъвместим с твоя продукт и с малко усилия ще можеш да адаптираш кода си да работи с него.

Ако не разбираш, можеш да проследиш дискусиите, ако има такива, в стандартизиращата организация и да прецениш струва ли си да опитваш сам или по-добре да изчакаш поне работен вариант, за да се ориентираш в препоръчителните практики.

От дискусиите, които съм наблюдавал при приемането на IETF стандартите (документите RFC), светилата в областта, независимо от коя фирма са, работят заедно по проблемите, споделят опит, обсъждат, защитават идеите си, надявайки се, че това ще доведе до резултат, от който ще спечелят всички.

- преди и след приемане на стандарт

Първо се пускат бета-варианти. Понеже в повечето случаи хората не се интересуват особено много от проектите, по които се работи, но се интересуват от нещата, които скоро могат да станат стандарт, бета-стандарта ще стигне до много организации, което ще им помогне да се съобразят с бъдещия официален документ, както и да тестват и дадат препоръки за бетата.

След приемането на стандарт обикновено всички се опитват да съобразят решенията си с него. Доста често има изключения, обаче, обикновено от фирми, които се чувстват достатъчно силни, за да наложат волята (бизнес-интереса) си над останалите. Понякога става, понякога не; примери могат да се намерят и за двата варианта.

- от кого се налагат тенденциите

Трудно е да се каже. В общият случай - от пазара. Хората решават такива и такива проблеми и стандартът се опитва да предложи универсален начин за решаването на тези проблеми, с надеждата, че това ще създаде много, разнообразни продукти.

Понякога седя и си мисля, а понякога само си седя ...

Основното предимство от спазването на стандарт е, че стандартната творба има шанс за по-дълъг живот, в смисъл - по-лесна е за преизползване, развитие и т.н. Друг момент е, че стандарта улеснява (поне такава е идеята) на _дебелопер(кат)а_. Булшитове от сорта дето клиентите (нормалните потребители) щели да пърхат от кеф понеже всичко е стандартно не ги намирам убедителни (косвена полза клиентите разбира се имат - по-лесно за дебелопване - по-голям шанс да е качествено).
Колкото до това, трябва ли да чакаш - обикновено преди да стане кандидат за стандарт, чудото е било широко използвана библиотека/среда/купчина_бест_практисес и може спокойно да го използваш и без да е формален стандарт.
Доста от стандартите тръгват от яка технология на голяма компания (стига компанията да не се казва Sun (примерно :))
Разработката предполагам е доста весела - комитет от заинтересовани и всеки дърпа чергата към себе си и иска неговите хави да са стандарт :)

Така че ако няма някакъв принципен недостатък в самия стандарт, значи той върши работа и няма технологична причина да не се спазва.

1. Това че върши работа,означава ли че някой друг не може да измисли три дена след това още по-добър от техническа страна стандарт?!?

2. За да го наричаш стандарт,той вече е натоварен политически да бъде наложен като стандарт. Така че техническата страна идва на втори план.

Стандарт лесно не се измисля. Това, което казваш, може да стане само, ако другият човек / организация работи паралелно на мен. Е, може и да го осени гениално хрумване, но това е рядкост.

Въпреки това, наистина, нещата се развиват и никак няма да е чудно ако не след три дни, след три месеца да има ново виждане. В което обаче няма лошо. Най-вероятно ще бъде лесно да се направи конвертор между двата стандарта и всички да почнат да ползват новия, по-хубав стандарт.

Разбира се, ще е необходимо известно време, докато съществуващия софтуер почне да разбира от новия стандарт, но дотогава ще караме със стария и ще разчитаме на конверторите.

Всъщност, честата смяна на стандарта показва, че продукта / интерфейса все още не е узрял. След достигане на определено ниво на развитие е горе-долу все едно кой точно стандарт използваш, защото те са функционално почти еднакви.

Така че създаването на следващ стандарт означава принципен скок във възможностите, което неизменно е свързано с непълнота поради недокрай осъзнати взаимовръзки и следствия, от което директно следва, че този стандарт ще трябва също да се изчиства. Затова нормалното е хората да не го използват, докато не узрее досататъчно.

Не мисля, че стандартът трябва да бъде наложен политически. Има и де-факто стандарти, примерно IP, ethernet, PCI... Всички телеком стандарти (на практика хардуерни + софтуерно интерфейси) всъщност са "препоръки". Стандартът сам по себе си е начин да се прави нещо; хората го спазват, защото им е изгодно да го спазват, а не защото има закон, който ги задължава.

Понякога седя и си мисля, а понякога само си седя ...

Малко по-нагоре и Masklin е писал разни неща, коментарът ми е повлиян от постингите и на двама ви.

То май поради разни такива причини стандартите закъсняват спрямо вече навлязло отдавна положение.

Никой не бърза да одобри стандарт. Тук не времето е основен фактор, а съдържанието. Все пак, стандартът не трябва да е подходящ за нещо и някого, а за цяла област. Всичко трябва да се вземе под внимание.

И идеята не е да се наложи нещо в началото, а да се обобщят действащи идеи и да се изчистят от проблеми. Ако приемем, че разнообразието на реализации се разширява все повече с времето, то стандартът може в даден момент да ограничи това неконтролирано разнообразие и да пъхне развитието на разнородности в разумни граници.

П.П. Гледам, че в клуб web design напоследък обръщат сериозно внимание на валидния html. Може и да бъркам, но май е имало време, когато е действал принципът: "Разбира ли го браузерът? Разбира го. К'ъв ти е проблемът, тогава?"

Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...

стандартите разкриват неподозирани нови хоризонти. Особено се забелязват тези хоризонти в условията на малка до средна нашенска Частна (с главно "Ч") софтуерна фирма, чийто едноличен шеф е "прозрял пътя към единственото", чрез сертифициране по ISO 9001.

Алгоритъмът е следния: Първо се назначават (по възможност "само докато тръгне") разбирачи по ISO 9001 (разбирай- само 1 брой такива), на заплата по възможност- умерена. Разбирачите(чките) владеят доста по-добре "пасианса" и "миничките", но това е една друга тема. С охкане и пъшкане минава някак си сертифицирането и после се почерпваме... А самата работа на малкия човечец (разбирай - девелопера) леко се променя. Досега е успявал да спастри някой и друг час на ден за самоусъвършенстване, сърфиране, даунлоадване, гамене и ровене по форуми, но вече тези пролуки трябва да ги отделя за попълване и предаване на рядко скучни документи и да прави поразително досадни неща свързани със системата ISO 9001. Естествено, това допълнително натоварване не се плаща допълнително с пари, а само с виртуални, бъдещи такива: "След като сме сертифицирани и клиентите ще се изпопребият да ни търсят!"


Виж, в научните среди много не се говори за стандарти. Представяш ли си думите "Грид" и "стандарт" в едно изречение, а!? ... Е, сега де, утре може и това да стане ...

Много си прав, с едно малко изключение... Обикновенно на дребната до средната фирма не и пука за ISO, докато не види как някоя и друга тлъста поръчка се изнизва като последната петолевка на девелоперско сборище в квартална кръчма - бързо, лесно и безвъзвратно като Линукс инсталация... Със съответните псувни и мечти по доброто старо време...
Честно казано, 90% от шефовете които познавам са заети предимно с тежкия проблем как да закарат някоя по-сочна колежка на семинар без да допуснат if ... else ... конструкции в алгоритъма. Така че проблема с разните му стандартизации се решава точно като проблема с пожарогасителя - по-най евтиния и показен начин.
Оттам нататък проблема на девелопера се усложнява наистина много. Ако е хитро копеле, той знае че всяка допълнителна документация яде от работното време и съответно носи допълнителни точки по правилото, че не е важно да свършиш една работа, а да я отчетеш. Ако е млад, ентусиазиран и пълен с вяра в светлото бъдеще, отворения код и че жените се привличат предимно с мозък, тогава получава още една невероятна възможност - да демонстрира как попълването на N формуляра може спокойно да замени пишпаузата след диетичния обяд и мечтите по русото създание с големите, ъъъ, информационни масиви и дългите ъъъ, шини за данни на съседната маса...

взе да им пука за ISO, ама и по други причини. След 2-3 години ще влезем в ЕС и е съвсем друго да имаш тапията. А ако отложат сертифицирането за тогава и ... ще "паднат" вече на европейския ценоразпис.
Ти описваш работата в условия на стандартизация малко бюрократично - не е важно да се свърши, а да се отчете. Американците отдавна са прозряли, че има разлика между "добре направено" и "стандартизирано" и железно са въвели съответните процедури. Така най-малкото се избягват безкрайните и безплодни спорове между клиент и девелопер - "добре ли направено, не е ли".

Показателно е, колко пъти сме гледали в американски филми как някой се тюхка за как е направено нещо, а съответният "отговорен фактор" казва тежко "Това е положението - стандартна процедура!" и ... дискусията приключва.

Това, което казваш, може да стане само, ако другият човек / организация работи паралелно на мен.

Точно това имах предвид.

Най-вероятно ще бъде лесно да се направи конвертор между двата стандарта и всички да почнат да ползват новия, по-хубав стандарт.

Е извинявай, дори да е след три месеца - кой стандарт може да се наложи за три месеца?? Това според мен изобщо не е стандарт!

Не мисля, че стандартът трябва да бъде наложен политически.

Ако някоя компания предложи стандарт, тя вече е решила да го наложи ако може. Така че той вече е натоварен политически, без значение дали ще се превърне в де-факто стандарт или не.

Иначе съм съгласен с теб

... се изнизва като последната петолевка на девелоперско сборище в квартална кръчма ...

Колко вярно казано - направо взето от живия живот!

И също: ...бързо, лесно и безвъзвратно като Линукс инсталация...

Бих добавил само: на компютър с процесор AMD и VIA или SiS чипсет.

...като ISO. Не смогваме да прочетем всички "произвеждани" документи:)

Абе минало е покрай ISO, ама нейсе..

Дали би ни светнал кой точно е ISO9001 под-стандарта софтуерни фирми?
Преди няколко години май нямаше такъв... Па кой как се сети си наглася примерно съответния ISO9001 за обувна фабрика, така щото да му върши работа във фирмата за разработка на софтуер...

Не ти разбрах точно въпроса, но виж това:

ISO/IEC 90003:2004 - Software engineering -- Guidelines for the application of ISO 9001:2000 to computer software може да ти помогне. За съжаление, документите които са дадени там не са безплатни.

Но иначе от този сайт [линк] може доста да се прочете за стандартите.

Върти ми се в главата 9028...

Мечтата е мисъл, мисълта е идея, всяка идея се реализира. Аз не мечтая, а реализирам идеите си.

ISO 9028:1989 е за "Rubber -- Dissolution by acid digestion" - дефинира методите за разлагане на каучук и гума с азотна и сярна киселина.

А каква е разликата между тях?
Понеже СММа поражда в мен една съвсем ясна мисъл: "бегай, бегай....докато е време" :)

Някога ми се мотаеше една книжка "A Comparison of ISO 9001 and
the Capability Maturity Model for Software" на Mark Paulk - там беше обяснено добре, въпреки, че е издадена преди няколко години. Ама май съм я загубил вече. Сигурно може да се намери по Интернет някое по-ново издание "на пират".